Debugging with Git Bisect
Utilize `git bisect` to efficiently pinpoint the exact commit that introduced a bug, saving valuable debugging time.
Debugging with Git Bisect is a free Git Advanced: Monorepo, Submodules & Workflows lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Git Advanced: Monorepo, Submodules & Workflows learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
What is Git Bisect?
Imagine a bug appears in your project, but you're not sure which recent change caused it. Manually checking each commit can be a huge time sink!
git bisect is a powerful Git command that uses a binary search algorithm to quickly find the exact commit that introduced a bug.
The Binary Search Advantage
How does git bisect work so fast? It's like a game of 'hot or cold' with your commit history.
- You tell Git a commit you know is bad (has the bug).
- You tell Git a commit you know is good (before the bug existed).
- Git picks a commit roughly in the middle and asks you to test it.
- Based on your feedback, it halves the search space, repeating until the culprit is found.
Starting Your Bisect Hunt
To begin, first you need to tell Git you're starting a bisect session. Then, you mark the known 'bad' (buggy) commit and a known 'good' (working) commit.
You can use commit hashes, branch names, or tags.
git bisect start
git bisect bad HEAD
git bisect good <known_good_commit_hash>The Iterative Process: Test & Mark
After you define your good and bad commits, Git will automatically check out a commit in the middle of that range. Your job is to test the code at this commit.
- If the bug is present, mark it as bad.
- If the bug is NOT present, mark it as good.
Git will then move to the next commit, halving the remaining search space.
Marking a Commit
Once you've tested the currently checked-out commit, use these commands to tell Git whether it's good or bad:
- To mark the current commit as bad:
git bisect bad - To mark the current commit as good:
git bisect good
Git will then automatically check out the next commit to test.
git bisect bad
# OR
git bisect goodNarrowing Down the Problem
You'll repeat the 'test and mark' process. With each step, git bisect gets closer to the single commit that introduced the bug. It's much faster than checking commits one by one!
For a range of 100 commits, it takes at most 7 tests (log2(100) ≈ 6.64).
Found the Culprit!
Eventually, git bisect will narrow the range down to a single commit. It will then report the first 'bad' commit found, which is your bug introducer!
After finding the bug, it's crucial to exit the bisect session to return your repository to its original state (usually the branch you were on when you started).
git bisect resetHandling Untestable Commits
Sometimes, git bisect might land on a commit that can't be tested (e.g., it doesn't compile, or dependencies are broken). In such cases, you can tell Git to skip it:
git bisect skip
Git will then pick another commit to test, making sure to exclude the skipped one from the potential range of the bug.
git bisect skipAutomating with Git Bisect Run
For even faster debugging, you can automate the testing process using git bisect run. This command takes a script that performs the test and exits with specific codes:
0: The commit is good.1-127125): The commit is bad.125: The commit should be skipped (e.g., cannot build).
Git will then run the script automatically for each commit until the bug is found.
#!/bin/bash
# Example test script for git bisect run
# Replace 'make test' with your actual test command
if make test;
then
exit 0 # Tests passed, commit is good
else
exit 1 # Tests failed, commit is bad
fiBisect Workflow Check
Which of the following commands are essential when performing a manual git bisect to find a bug?
Debugging Power-Up!
You've mastered git bisect! This powerful tool transforms bug hunting from a tedious chore into an efficient, systematic process using binary search.
- Start with
git bisect start, defining good and bad commits. - Test and mark commits as
goodorbad. - Use
git bisect skipfor untestable commits. - Automate with
git bisect runfor fast, hands-free debugging. - Always finish with
git bisect reset.
Happy bug hunting!
Frequently asked questions
Is the “Debugging with Git Bisect” lesson free?
Yes — the full text of “Debugging with Git Bisect” is free to read here on the web, and the Git Advanced: Monorepo, Submodules & Workflows course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Git Advanced: Monorepo, Submodules & Workflows course, upgrade to CoddyKit PRO.
What will I learn in “Debugging with Git Bisect”?
Utilize `git bisect` to efficiently pinpoint the exact commit that introduced a bug, saving valuable debugging time. You practise Git Advanced: Monorepo, Submodules & Workflows with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Git Advanced: Monorepo, Submodules & Workflows?
No prior experience is required. Git Advanced: Monorepo, Submodules & Workflows on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Debugging with Git Bisect” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Git Advanced: Monorepo, Submodules & Workflows lesson?
Yes. Every Git Advanced: Monorepo, Submodules & Workflows lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.