Git Bisect
Binary search through history to find the commit that introduced a bug
When a bug appeared somewhere in the last hundred commits but you don't know exactly where, Git Bisect finds it with a binary search instead of checking commits one by one. Repository → More → Bisect… opens the dialog.
How it works
Bisect needs two reference points:
- A Bad commit — one that has the bug (often
HEAD). - A Good commit — an older one that doesn't (a tag like
v1.0, or a hash).
Git checks out a commit roughly halfway between them. You test it and tell GitBor whether the bug is present; each answer halves the range, so even hundreds of commits are narrowed down in a handful of steps.
Starting a session
- Open Repository → More → Bisect….
- Fill in Bad commit (e.g.
HEAD) and Good commit (e.g.v1.0or a hash). - Click Start Bisect — GitBor checks out the midpoint.
During the session
The dialog shows the current commit under test and an estimate of steps remaining. Build and test that checkout, then mark the result:
| Button | When to use it |
|---|---|
| Good | The bug is not present here. |
| Bad | The bug is present here. |
| Skip | This commit can't be tested (won't build, unrelated breakage) — Git picks a nearby one instead. |
A live Output log mirrors the raw git bisect output. When the range narrows to one commit, GitBor reports Found! — that's the culprit.
Finishing
Click Abort Bisect to end the session and return your working tree to where it was before you started. Always do this when you're done — whether or not the culprit was found — so you're back on your normal branch.