< All Topics

Git Bisect

git bisect
Git bisect – GeeksforGeeks

git bisect is a command that helps you find the exact commit that broke your game using a Binary Search algorithm.

Instead of checking every single change one by one (which takes forever), it cuts your commit history in half repeatedly until it isolates the bug.

The Problem Scenario

  • Two weeks ago (Commit A): The game was working perfectly.
  • Today (Commit Z): The player falls through the floor when they jump.
  • In between: You and your team made 100 commits (added code, changed art, updated plugins).

You have no idea which of those 100 changes caused the bug. Checking them all one by one would take all day.

How Git Bisect Solves It (The “High-Low” Game)

  1. You tell Git: “Current version is BAD. Version from 2 weeks ago was GOOD.”
  2. Git calculates the middle commit (Commit #50) and automatically checks it out.
  3. You test the game.
    • Is the bug there? You tell Git “Bad”. Git knows the bug happened in the first half (Commits 1-50).
    • Is the bug gone? You tell Git “Good”. Git knows the bug happened in the second half (Commits 51-100).
  4. Git cuts the remaining half in half again (Commit #25 or #75).
  5. Repeat until only one commit remains.is this an automation?No, git bisect does not look at your code or scan for bugs. It does not know what a “bug” is.
    Think of git bisect as a Time Machine Operator.
    • Git’s Job: To transport your computer back in time to a specific date.
    • Your Job: To play the game and tell Git, “Yes, the bug exists in this time period” or “No, the game works here.”
      Here is exactly what you do, step-by-step, in a real scenario.

The Scenario: “Mario can’t jump anymore”

You are making a platformer.

  • Commit 100 (Today): You press Spacebar, and Mario doesn’t jump. (Broken).
  • Commit 1 (Last week): You know Mario was jumping fine back then.

You don’t know which of the 99 commits in between broke the jump.

The Workflow: What YOU do vs. What GIT does

Step 1: The Setup

You type: git bisect start
You type: git bisect bad (Because today is broken).
You type: git bisect good [commit-hash-from-last-week] (Because last week was safe).

Step 2: The First Jump (Git helps you)

Git says: “Okay, I have checked out Commit 50 (halfway).”

  • At this exact moment, Git changes all the files on your hard drive to look exactly like they did on Commit 50.

You do this:

  1. Go into Unity/Unreal (it might ask to reload).
  2. Press “Play”.
  3. Press Spacebar.
  4. Observation: Mario jumps perfectly!
  5. Conclusion: The bug was introduced after Commit 50.

You type: git bisect good

Step 3: The Second Jump

Git says: “Okay, since 50 was good, the bug is in the second half. I have now checked out Commit 75.”

  • Git changes your files on the hard drive to look like Commit 75.

You do this:

  1. Go back to Unity/Unreal (Reload/Recompile).
  2. Press “Play”.
  3. Press Spacebar.
  4. Observation: Mario does not jump.
  5. Conclusion: The bug was introduced before Commit 75 (between 50 and 75).

You type: git bisect bad

Step 4: The Final Jump

Git says: “Okay, narrowing it down. Checking out Commit 62.”

You do this:

  1. Reload/Recompile.
  2. Press “Play”.
  3. Press Spacebar.
  4. Observation: Mario jumps!

You type: git bisect good


The End Result

You repeat this a few more times (it’s very fast). Eventually, Git will stop and print a message:

Commit 73 is the first bad commit
Author: Dave
Message: “Updated Player Input System”

Now you know: Dave broke the jump button in Commit 73. You open that specific commit, look at the code Dave wrote, and you will see exactly why it broke.