The Blame Game

git blame shows which commit last changed each line. git blame --ignore-revs keeps formatting and refactor commits from hiding the useful history.

git blame shows which commit last changed each line in a file. It is useful when you need to understand why code exists, who last touched it, and which commit gives you the surrounding context.

How Do You Use git blame?

Open your terminal, navigate to your repository, and type:

git blame src/index.js

You will get output that looks something like this:

9e8f7a2 (Alice    2025-06-15 10:30:00 -0700  1) import React from 'react';
9e8f7a2 (Alice    2025-06-15 10:30:00 -0700  2)
f2a1b3c4 (Bob     2025-05-20 14:15:00 -0700  3) const MyComponent = () => {
d5e6f7g8 (Charlie 2025-06-01 09:00:00 -0700  4)   // This is a new comment
a9b8c7d6 (Alice   2025-06-15 10:30:00 -0700  5)   return (

Each line shows:

  • the commit hash
  • the author
  • the commit date, and
  • the line number.

You can instantly see who wrote what and when.

The Problem: When Blame Gets... Blurry

But sometimes, git blame can get a little messy. Let's say you run a code formatter (like Prettier) across your entire codebase. Suddenly, thousands of lines are "blamed" on that single formatting commit, even though the actual logic was written by someone else, much earlier. Or maybe you did a massive refactor that touched a lot of files without changing the underlying functionality.

This is where git blame becomes less helpful. It points fingers at the formatter (or the refactorer), obscuring the original author.

When Should You Use git blame --ignore-revs?

Git version 2.23 introduced git blame --ignore-revs. This lets you tell git blame to ignore specific commits when tracing line history.

So, for those massive formatting or refactoring commits that just mess up your blame history, you can simply tell Git to skip over them.

How to Use It:

First, you need to identify the commit hashes you want to ignore. You can find these using git log or by running git blame and spotting the noisy commits.

Let's say you have a commit with hash abcdef123456 that was your big formatting commit. You can ignore it like this:

git blame --ignore-revs abcdef123456 src/index.js

But what if you have multiple commits to ignore? Typing them all out on the command line can be a pain. That's where the ignore-revs-file comes in handy!

The ignore-revs-file:

You can create a simple text file (though the name can be anything, the convention is to use .git-blame-ignore-revs) in your repository's root and list all the commit hashes you want to ignore, one per line.

Example .git-blame-ignore-revs file:

abcdef123456
7890def12345
fedcba987654

Now, you can tell git blame to use this file:

git blame --ignore-revs-file .git-blame-ignore-revs src/index.js

Now git blame will skip over those specified commits, giving you a cleaner history of who changed the code that actually matters. This is useful in projects with frequent automated changes or large-scale refactors.