How to Find the Commit That Introduced a Bug with git bisect

In this tutorial, you'll learn about How to Find the Commit That Introduced a Bug with git bisect. We cover key concepts, practical examples, and best practices.

The Problem

A feature that was working last week is now broken. You do not know which commit introduced the bug, and the project has dozens of commits since the last known-good version. Manually checking each commit is impractical.

Quick Fix

Step 1: Start the bisect session

Tell Git to start a binary search:

git bisect start

Step 2: Mark the current commit as bad

The current HEAD contains the bug:

git bisect bad

Step 3: Mark the last known-good commit

Provide a commit hash, tag, or reference where the feature worked:

git bisect good v1.0.0

Bisecting: 12 revisions left to test after this (roughly 4 steps)
[3f4a5b6c7d8e] Refactor authentication module

Step 4: Test each midpoint commit

Git checks out the midpoint commit. Test the bug:

npm test

If the bug is present:

git bisect bad

If the bug is absent:

git bisect good

Git narrows the range by half each time.

Step 5: Identify the first bad commit

After a few steps, Git reports the exact commit:

3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2f is the first bad commit
commit 3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2f
Author: Dev Name <dev@example.com>
Date:   Mon Jun 20 14:30:00 2026 +0000

    Refactor authentication module

Step 6: End the bisect session

Return to the original HEAD:

git bisect reset

Previous HEAD position was 3f4a5b6... Refactor authentication module
Switched to branch 'main'

Step 7: Automate with a test script

Run the entire bisect automatically:

git bisect start HEAD v1.0.0
git bisect run npm test

Alternative Solutions

Use git log --first-parent for linear history

If your bisect goes through merge commits, --first-parent skips side branches:

git log --first-parent --oneline

Skip commits that cannot be tested

If a commit is broken for unrelated reasons, skip it:

git bisect skip

Common Mistakes to Avoid

Marking a commit as bad when the bug is intermittent. A flaky test environment can give false positives. Run tests multiple times to confirm.

Not specifying a good commit that is old enough. If the good commit is also broken, bisect will report the wrong first bad commit. Choose a known-stable release.

Resetting before the bisect is complete. If you run git bisect reset before finding the bad commit, you lose the bisect state and must start over.

Pro Tips

Write a reusable bisect script. Create a script that sets up the environment and runs tests so you can pass it to git bisect run every time.

Use git bisect visualize. During a bisect, run git bisect visualize to see the remaining commits in a graph, helping you understand the search space.

Skip flaky commits. If a commit cannot be tested due to unrelated infrastructure issues, use git bisect skip to exclude it from the search.

Prevention

• Write a regression test for every bug fix so git bisect can run automatically.
• Make frequent, small commits to make bisect more precise.
• Tag releases so you always have known-good reference points.