DEV Community

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

Posted on • Originally published at Medium

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

#webdev #programming #git #productivity

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

Top comments (0)