Debugging Git Commits: Finding Exactly What Broke

Comparing Git Commits to Debug a Regression

A feature worked yesterday. It’s broken today. I don’t guess when this happens — I compare the two commit states directly and let Git tell me exactly what changed. Commit comparison is the practice of diffing two points in a repository’s history to isolate which commit introduced a regression. Here’s the workflow I actually use: pick a good and a bad commit, diff them precisely, and recover only what you need without dragging the rest along with it.

Step 1: Identify the Commit Range with git log

Start with the shape of your history:

git log --oneline --decorate --graph

From that graph, pick two points:

• GOOD_COMMIT — the last commit you know worked.
• BAD_COMMIT — the first commit where things broke.

Everything else in this workflow hangs off those two references.

The range GOOD_COMMIT..BAD_COMMIT covers every commit in between — that’s what git diff, git log -p, and the recovery commands in the next steps all operate on.

Step 2: Compare Commit States with git diff and git show

git diff is a Git command that compares two references — commits, branches, or the working tree — and prints the line-by-line changes between them. Once you have your range, git diff shows you exactly what changed:

git diff GOOD_COMMIT..BAD_COMMIT

Narrow it to one file when you already suspect where the regression lives:

git diff GOOD_COMMIT..BAD_COMMIT -- path/to/file.py

git show is a Git command that displays a single commit’s metadata (author, date, message) together with its full patch. When you want the full picture on the bad commit in one go, git show gives you that:

git show BAD_COMMIT

Step 3: Inspect the History in the Range with git log -p

A diff tells you what changed overall, but sometimes you need it commit by commit. git log is a Git command that lists commits reachable from a given range; with -p, it also prints each commit’s patch:

git log --oneline GOOD_COMMIT..BAD_COMMIT
git log -p GOOD_COMMIT..BAD_COMMIT

The first command gives you a quick list of suspects. The second shows the actual patch for each one, so you can spot which commit introduced the regression rather than just knowing it happened somewhere in the range.

Step 4: Create a Safety Branch Before Recovery

🔒 Subscribe to keep reading.

Step 5: Recover Good Changes with git cherry-pick or git revert

🔒 Subscribe to keep reading.

Step 6: Resolve Merge Conflicts During Cherry-pick or Revert

🔒 Subscribe to keep reading.

Mental Model: Commits as Before-and-After Photographs

🔒 Subscribe to keep reading.

Checklist for Debugging a Regression by Comparing Commits

🔒 Subscribe to keep reading.

Summary: Debugging Git Regressions by Comparing Commits

🔒 Subscribe to keep reading.

References

🔒 Subscribe to keep reading.