Simulate git blame functionality to see commit history and authorship of code lines. Part of the DevTools Surf developer suite. Browse more tools in the Developer Utilities collection.
Use Cases
Identify who wrote a confusing block of code to ask them directly rather than guessing context.
Find the commit that introduced a bug by tracing the origin of a specific variable assignment.
Audit code ownership for a compliance review or codebase handover.
Determine if a line was introduced in the same commit as a related feature or independently.
Tips
Use blame to find the commit that introduced a specific line, then use 'git show <hash>' for full context including the commit message and PR link.
Ignore whitespace-only commits with 'git blame -w' to avoid attribution noise from reformatting runs.
In the simulator, annotate line ranges to practice blame on a targeted section rather than an entire file.
Fun Facts
'git blame' was originally called 'git annotate' in early git versions (2005). The rename to 'blame' was intentional — Linus Torvalds thought 'annotate' sounded too gentle.
GitHub renders blame in the UI and hyperlinks each commit hash — clicking a line opens the full diff that introduced it, a workflow used by millions of developers daily.
The -C flag in git blame detects code moved from other files, attributing lines to their original author rather than whoever copy-pasted them.
FAQ
Does blame work on renamed files?
With 'git blame --follow', yes — git traces the file through renames. The simulator shows the effective behavior with and without this flag.
What does the commit hash column mean?
Each line shows the abbreviated hash of the commit that last modified it, along with author and date. This is the most recent change, not necessarily the original author.
Can I ignore mass reformatting commits?
Use 'git blame --ignore-rev <hash>' or a .git-blame-ignore-revs file to exclude specific commits. Useful after running a formatter like Prettier across the codebase.
