git blame Command in Git: Syntax, Options & Practical Examples

The git blame command helps you trace the history of changes in a file by showing who last modified each line and when the modification occurred. It is commonly used during debugging or code reviews to identify the author and commit responsible for a specific line of code.

You can also refer to our Git Command Cheat Sheet with Examples for a quick reference of other history tools, or inspect commit details using git show.

By analyzing commit metadata such as the author, timestamp, and commit hash, developers can quickly understand how a file evolved and investigate the context behind changes.

git blame Quick Cheat Sheet

The following table summarizes the most commonly used git blame commands, flags, and options to inspect line-level changes, identify contributors, and trace commit history.

git blame Command Syntax

Basic git blame command syntax

The general syntax of the command is:

git blame [options] <file>

Example:

git blame main.c

You can also specify a revision:

git blame <revision> <file>

Example:

git blame HEAD~1 main.c

Understanding git blame output fields

Running git blame displays metadata about each line in the file.

Example output:

3f2c4d8a (Alice 2024-02-12 14:05:21 +0530 1) #include <stdio.h>
7a1b9c21 (Bob   2024-02-13 09:30:10 +0530 2) int main() {
7a1b9c21 (Bob   2024-02-13 09:30:10 +0530 3)     printf("Hello World");

Commit hash, author, timestamp and line content explained

Each line of the output includes the following fields:

Example interpretation:

3f2c4d8a (Alice 2024-02-12 14:05:21 +0530 1) #include <stdio.h>

• 3f2c4d8a → commit that introduced the change
• Alice → author of the change
• 2024-02-12 → date of modification
• 1 → line number
• #include <stdio.h> → code line

Difference between git blame and git log

Both commands inspect repository history but serve different purposes. The way history is recorded depends on whether you perform a Git Merge or a Git Rebase to integrate changes. You can compare these specific changes using git diff.

Example:

git log main.c

Displays commit history of the file.

git blame main.c

Displays which commit modified each line.

Identify Who Modified a Line in Git

Find the author of a specific line

Run the blame command:

git blame config.py

Example output:

5a6c2f0d (John 2024-03-10 11:20:01 +0530 10) DATABASE_URL = "localhost"

This indicates John modified line 10.

Trace commit responsible for code changes

Use the commit hash to inspect the change.

git show 5a6c2f0d

This displays:

• commit message
• files changed
• code differences

Identify when a line was last modified

The timestamp in the output shows when the change occurred.

Example:

John 2024-03-10 11:20:01

This helps identify recent modifications. If you have local changes that aren't committed yet, you may want to Save changes temporarily with Git Stash before running a blame.

View commit hash associated with a line

You can inspect the commit using:

git log -p 5a6c2f0d

This displays detailed patch information.

Track Changes in a File Using git blame

Inspect the history of a file line by line

Run:

git blame server.js

This shows the commit responsible for every line.

Determine which developer introduced a change

Example output:

9c3f2b1a (David 2024-01-11 08:12:34 +0530 22) return calculateTotal();

This indicates David introduced the change on line 22.

Detect recently modified lines

Recent modifications can be identified by checking timestamps in the output.

Example:

(Emily 2024-03-25)

Understand how blame helps in debugging code

Developers often combine git blame with other commands.

Example workflow:

git blame api.go
git show <commit-id>

This helps understand why a change was introduced.

View Specific Lines Using git blame

Show blame information for selected lines

Use the -L option.

git blame -L 10,20 main.c

This displays blame for lines 10 through 20.

Use -L option to limit blame output

You can also specify the number of lines.

git blame -L 15,+5 main.c

This shows five lines starting from line 15.

Inspect a range of lines in large files

Example:

git blame -L 100,120 config.yaml

Useful for analyzing large files.

Investigate only the lines related to a bug

Example:

git blame -L 45,60 app.py

This helps quickly identify:

• who changed the code
• when it was changed
• which commit introduced the change

Track Moved or Copied Code

When developers refactor code, lines may be moved within the same file or copied from other files. By default, git blame may attribute these lines to the commit that performed the refactoring instead of the original author. Git provides options like -M and -C to track the original source of moved or copied code.

Detect moved lines within the same file using -M

The -M option tells Git to detect lines that were moved within the same file. This is useful during refactoring when code blocks are reorganized.

Example:

git blame -M main.c

Git will attempt to find the original commit where the code was first introduced, even if the lines were moved elsewhere in the file.

Detect copied lines across files using -C

The -C option detects lines that were copied from other files in the repository.

Example:

git blame -C main.c

This helps identify when code was reused or copied from another source file.

You can increase the detection level by repeating the option:

git blame -C -C main.c

This instructs Git to perform deeper searches for copied code.

Identify original author of copied code

When code is copied from another file, git blame -C attempts to locate the original author and commit that introduced the code.

Example workflow:

git blame -C utils.c

The output may reveal that the line originally came from a different file and commit.

View Author Email Instead of Username

Display email addresses using -e option

Use the -e option to show the author's email address.

Example:

git blame -e main.c

Example output:

3f2c4d8a (alice@example.com 2024-02-12 14:05:21 +0530 1) printf("Hello");

Identify contributor contact information

Showing the email address helps identify the contributor when multiple developers may share similar usernames.

This can be useful for:

• contacting contributors
• investigating code ownership
• resolving code review questions

Use blame output for audit purposes

Organizations often use git blame for code auditing. By showing email addresses, teams can trace exactly who authored a line of code.

Example:

git blame -e config.yaml

This provides a clear record of authorship.

Improve collaboration tracking

Displaying emails can also help maintain accurate contributor records across distributed teams and large projects.

Investigate Recent Changes

View changes made after a specific date

Git allows filtering blame output based on time using date-based options.

Example:

git blame --since="2 weeks ago" app.js

This displays lines modified within the last two weeks.

Use --since option with git blame

The --since option restricts blame output to commits made after a specific date.

Example:

git blame --since="2024-01-01" server.js

This is useful when reviewing code changes made during a certain time period, such as auditing changes for a specific Git Tag or release version.

Track changes during a release cycle

During release cycles, developers often need to identify changes made during a specific sprint or milestone.

Example:

git blame --since="1 month ago" config.go

This helps isolate changes introduced during the release process.

Debug Code Issues Using git blame

Find the commit that introduced a bug

When a bug appears in a particular line, git blame can help locate the commit responsible.

Example:

git blame app.py

Locate the problematic line and note the commit hash.

Then inspect the commit:

git show <commit-id>

This shows the exact change that introduced the bug.

Identify developers responsible for a change

The blame output reveals the developer responsible for modifying each line.

Example:

7a1b9c21 (Bob 2024-02-13 09:30:10 +0530 42) processUserInput();

This indicates Bob last modified line 42.

Combine git blame with git log for debugging

A common debugging workflow involves combining git blame with git log.

Example:

git blame api.go
git log -p <commit-id>

This helps understand the reasoning behind the change.

Investigate regressions in source code

When a previously working feature breaks, developers can use git blame to identify when the problematic code was introduced.

Example workflow:

git blame module.js
git show <commit-id>
git log --oneline

This process helps pinpoint regressions quickly and identify the commit that caused the issue. If needed, you can restore changes using git restore or learn how to revert a Git commit to undo a problematic change permanently.

Use git blame in Large Projects

Analyze large files efficiently

When working with large source files, running git blame on the entire file may produce a lot of output. Developers often combine it with other filtering tools to focus on relevant sections.

Example:

git blame large_file.go

This command prints the author and commit responsible for every line in the file.

Combine blame with grep to locate problematic lines

Developers frequently combine git blame with tools like grep to locate problematic code quickly.

Example:

git blame server.js | grep "database"

This command identifies which developer last modified lines containing the keyword database.

Identify hotspots in large codebases

Hotspots are sections of code that change frequently or involve many contributors. Running git blame across key files helps identify such areas.

Example workflow:

git blame auth_service.go
git log auth_service.go

This helps understand which files or modules require frequent maintenance.

Use blame during code reviews

During code reviews, developers may want to understand the context of existing code before approving new changes.

Example:

git blame config.yaml

Reviewers can quickly determine:

• who wrote the code
• when the change occurred
• which commit introduced the change

Use git blame on Tagged Versions

Run git blame on a tagged release

You can run blame on a specific tag.

Example:

git blame v1.0 main.c

This shows the state of the file at the tagged release.

Investigate changes in previous releases

If an issue appears in a production release, developers may want to inspect the code from that version.

Example:

git blame v2.1 config.py

This helps determine which commit introduced a change before the release.

Compare blame results across versions

Developers can compare blame results between versions to see how the authorship of lines changed.

Example:

git blame v1.0 server.js
git blame v2.0 server.js

This comparison helps identify new contributors and modifications.

Debug issues introduced between releases

If a bug appears after a release upgrade, developers can examine the differences between versions.

Example workflow:

git blame v1.5 module.js
git blame v2.0 module.js
git diff v1.5 v2.0 module.js

This helps pinpoint changes that may have introduced the issue.

Use git blame with Branches

Inspect changes in different Git branches

You can run blame on a file in a specific branch.

Example:

git blame feature-login app.js

This shows the authorship of lines within that branch. If you need to see which branches are currently available, you can List all Git branches in your repository first.

Compare blame output between branches

Comparing blame results across branches helps identify which developer introduced changes in a feature branch.

Example:

git blame main api.go
git blame feature-auth api.go

This comparison reveals differences in code ownership.

Identify branch specific modifications

If a feature branch modifies certain sections of code, blame helps track those changes.

Example:

git blame feature-payment checkout.js

Developers can see which lines were modified as part of the feature.

Track feature branch contributions

Blame can help track contributions from developers working on different branches.

Example workflow:

git checkout feature-reporting
git blame report_generator.py

This helps review work before merging it into the main branch.

Use git blame with GitHub

GitHub provides a graphical interface to view blame information directly in the browser.

View blame directly on GitHub web interface

Navigate to a file in a GitHub repository and click the Blame button at the top of the file view.

This displays line-by-line commit information similar to the CLI output.

Identify contributors using GitHub blame view

The GitHub blame interface displays:

• commit hash
• author name
• commit date
• commit message

This makes it easy to identify who modified each line.

Navigate commit history from blame output

Each commit hash in the GitHub blame view is clickable. Clicking it opens the full commit details.

Developers can then inspect:

• commit message
• files changed
• code differences

Compare GitHub blame with CLI blame

Both the GitHub interface and CLI provide similar functionality.

Using both methods together allows developers to analyze code history efficiently.

Use git blame in Visual Studio Code

Many developers prefer working with Git tools directly inside their code editor. Visual Studio Code provides powerful Git integration through extensions like GitLens, which enhances the functionality of git blame by showing commit details inline.

Install GitLens extension for blame

GitLens is one of the most popular Git extensions for Visual Studio Code and provides advanced blame capabilities.

Steps to install GitLens:

1. Open Visual Studio Code (see our guide to Setup GitHub with VS Code if you are setting up your environment for the first time).
2. Go to the Extensions panel
3. Search for GitLens
4. Click Install

Once installed, GitLens automatically enhances the editor with inline Git history information.

View inline blame annotations

GitLens can display blame information directly beside each line of code.

This includes:

• author name
• commit date
• commit message

Example inline annotation:

John Doe, 2 weeks ago • Fixed authentication bug

This allows developers to quickly understand the context of each line without leaving the editor.

Hover lines to view commit details

When hovering over a line in the editor, GitLens shows detailed commit information.

This popup typically contains:

• commit hash
• author
• commit message
• file changes

This makes it easy to inspect changes without running commands manually.

Navigate commit history from editor

GitLens also allows developers to navigate through commit history directly from the editor.

Features include:

• viewing commit history of a file
• comparing previous versions of a line
• opening commit diffs

These features make debugging and code exploration faster.

Use git blame in Bitbucket

Bitbucket provides a built-in Blame view that allows developers to inspect line-by-line commit history directly from the repository interface.

Access blame view in Bitbucket repository

To access the blame view in Bitbucket:

1. Open the repository
2. Navigate to the file you want to inspect
3. Click the Blame button near the top of the file viewer

Bitbucket will display commit information for each line.

Inspect commit details in Bitbucket UI

Each line in the blame view shows metadata including:

• commit hash
• author name
• commit date

Clicking the commit hash opens the detailed commit page where you can inspect the full diff.

Track line modifications in Bitbucket

Bitbucket's blame interface helps track:

• when a line was introduced
• who modified the line
• which commit made the change

This is useful for debugging or auditing changes.

Compare Bitbucket blame with GitHub blame

Although both platforms provide blame functionality, there are some differences.

Both platforms provide similar functionality for inspecting line history.

Advanced git blame Options

Ignore whitespace changes with -w

Sometimes changes involve only formatting updates such as indentation or spacing. The -w option ignores whitespace differences.

Example:

git blame -w main.c

This prevents whitespace-only changes from affecting blame results. If you find that the history has become messy, you can use Git Reflog to recover history and find the exact state you need.

Show original commit with --reverse

The --reverse option can be used to trace when lines disappeared from history.

Example:

git blame --reverse HEAD~5..HEAD main.c

This helps track when a line was removed or replaced.

Use blame with different revisions

You can inspect blame output for a specific commit or revision.

Example:

git blame v1.0 main.c

This shows how the file looked in that version.

Use blame with commit ranges

You can limit blame analysis to a range of commits.

Example:

git blame commit1..commit2 main.c

This allows developers to focus on changes introduced within a specific time period.

git blame vs git log vs git show

When to use git blame

Use git blame when you want to identify:

• who modified a specific line
• when the change occurred
• which commit introduced the change

Example:

git blame config.go

When git log is more useful

git log provides a chronological list of commits affecting the repository or a specific file.

Example:

git log server.js

This shows commit history including commit messages and authors.

When git show helps debugging

git show displays the details of a specific commit, including the code changes introduced.

Example:

git show <commit-id>

This command is useful when investigating a change found through git blame.

Combining multiple Git history tools

Developers often combine these commands to analyze issues more effectively.

Example workflow:

git blame app.py
git show <commit-id>
git log --oneline

Summary

The git blame command is a powerful Git tool used to inspect the history of changes in a file at the line level. It helps developers identify who modified a specific line, when the change occurred, and which commit introduced the modification.

In this guide, you learned how to use git blame with different options, analyze line history, track copied or moved code, inspect changes across branches or tags, and integrate blame functionality with tools such as GitHub, Bitbucket, and Visual Studio Code. These techniques are extremely useful when debugging issues, reviewing code, or understanding how a project evolved over time.

Official Documentation

For more detailed information about the git blame command and all supported options, refer to the official Git documentation:

• Git Blame Manual (git-scm.com)
• Git Log Documentation
• Git Show Documentation