Day 7/30 - git blame -L – See who changed a specific line in a file
Ruqaiya Beguwala

Ruqaiya Beguwala @ruqaiya_beguwala

About: 👨‍💻 | Software Developer | Open-Source Enthusiast | JavaScript & NodeJS | Think and write about code every single minute

Location:
India
Joined:
Apr 26, 2025

Day 7/30 - git blame -L – See who changed a specific line in a file

Publish Date: May 28
1 0

Introduction

When working with Git, tracking changes in a file is essential for debugging, code reviews, and understanding the evolution of a codebase. The git blame command helps identify who last modified each line in a file.

But what if you only care about a specific range of lines? That’s where git blame -L comes in! This powerful option allows you to narrow down the blame to a particular section of a file, making it easier to track changes efficiently.

In this guide, we’ll explore how to use git blame -L, practical examples, common use cases, and some handy tips.

How to Implement git blame -L

Basic Syntax

git blame -L {start},{end} {filename}
Enter fullscreen mode Exit fullscreen mode

{start} and {end} define the line range.
{filename} is the file you want to inspect.

Example 1: Checking a Single Line

To see who modified line 10 in app.js:

git blame -L 10,10 app.js
Enter fullscreen mode Exit fullscreen mode

Output:

^d3f2a1b (John Doe 2023-04-15 14:30:22 +0530 10) console.log("Hello, world!");
Enter fullscreen mode Exit fullscreen mode

Example 2: Checking a Range of Lines

To inspect lines 5 to 15 in index.html:

git blame -L 5,15 index.html
Enter fullscreen mode Exit fullscreen mode

Output:


^a1b2c3d (Jane Smith 2023-03-10 09:45:11 +0100 5) <div class="container">
^e4f5g6h (Mike Johnson 2023-05-20 16:22:05 -0700 6)   <h1>Welcome</h1>
...
Enter fullscreen mode Exit fullscreen mode

Example 3: Checking from a Line to EOF (End of File)

To see changes from line 20 to the end of script.py:

git blame -L 20, script.py
Enter fullscreen mode Exit fullscreen mode

Use Cases (With Examples)

1. Who Deleted a Critical Line

A security check was removed from a login function, and you need to find out who did it.

# Locate where the line used to be (e.g., validateAuthToken)
git grep -n "validateAuthToken"
# Output: src/auth.js:30:  validateAuthToken(token);

# Check the last commit that touched that line:
git blame -L 30,30 src/auth.js
# Output: ^a1b2c3d (Security Team 2023-01-10 09:00:00 +0000 30)   validateAuthToken(token);

# Find when it disappeared:
git log -L 30,30:src/auth.js
# This shows all commits that modified line 30
Enter fullscreen mode Exit fullscreen mode

2. Finding When a Specific Feature Was Introduced

You need to find out when a particular feature (e.g., a new API endpoint) was added to the codebase, but you only know a keyword or a line.

# First, find the line number using grep:
grep -n "addNewUser" server/routes.js
# Output: 45:router.post('/users', addNewUser);

# see when it was introduced
git blame -L 45,45 server/routes.js
# b5c8d9f1 (Dev Team 2023-05-15 10:20:30 +0100 45) router.post('/users', addNewUser);

# Inspect the commit for context:
git show b5c8d9f1

Enter fullscreen mode Exit fullscreen mode

3. Finding the Author of a Failing Test

A test fails randomly, and you suspect a race condition was introduced in an old version of the code.

# Find the test line:
grep -n "shouldHandleConcurrentRequests" tests/api.test.js
# Output: 112:  it('shouldHandleConcurrentRequests', async () => {

# Check when it was last modified:
git blame -L 112,112 tests/api.test.js
# Output: c3d4e5f6 (Senior Dev 2021-11-30 08:45:12 -0500 112)   it('shouldHandleConcurrentRequests', async () => {

# See if earlier versions had a different implementation:
git blame c3d4e5f6^ -L 112,112 tests/api.test.js     #The ^ checks the parent commit.
Enter fullscreen mode Exit fullscreen mode

Tips and Tricks

1. Combine with -C to Detect Moved Code

If a line was moved from another file, -C helps track its origin:

git blame -C -L 15,20 main.py
Enter fullscreen mode Exit fullscreen mode

2. Ignore Whitespace Changes with -w

Sometimes, whitespace changes clutter blame history. Use -w to ignore them:

git blame -w -L 10,15 styles.css
Enter fullscreen mode Exit fullscreen mode

3. Show Commit Hash and Date Only

For a cleaner output, use --porcelain:

git blame --porcelain -L 5,10 README.md
Enter fullscreen mode Exit fullscreen mode

4. Check Blame in a Different Commit

To see line history at a specific commit (abc123):

git blame abc123 -L 25,30 app.js

Enter fullscreen mode Exit fullscreen mode

Conclusion

git blame -L is an incredibly useful tool for pinpointing who modified specific lines in a file. Whether you're debugging, reviewing code, or tracking changes, this command helps you quickly identify contributors and understand modifications.

Key Takeaways:
✅ Use -L to check a specific line or range.
✅ Combine with -C or -w for better tracking.
✅ Great for debugging, code reviews, and audits.


Up next: git merge --no-ff – Force a merge commit (avoid fast-forward)


Daily advance GIT tips in your inbox—worth starting? Respond to my poll here🚀
For more useful and innovative tips and tricks, Let's connect on Medium

Comments 0 total

    Add comment