DEV Community

Rouan Wilsenach
Rouan Wilsenach

Posted on • Originally published at rouanw.com

Use git bisect to see when you broke the tests

I wanted to push a number of commits but my tests failed. Naughty me for not running them more often. Anyway, here's how to use git bisect to tell when they started failing.

git bisect start HEAD origin/main
git bisect run npm test
Enter fullscreen mode Exit fullscreen mode

You should get a result something like:

b73399a404433af29d95fb66d7b7facc1de49aa3 is the first bad commit
Enter fullscreen mode Exit fullscreen mode

And then you can run:

git bisect reset
Enter fullscreen mode Exit fullscreen mode

when you're done to exit bisect mode and go about fixing things.

A bit more explanation

Here are some details if you want them.

Start

git bisect start HEAD origin/main
Enter fullscreen mode Exit fullscreen mode

The syntax here is git bisect start <known-bad-commit> <known-good-commit>.

In the example above I've used HEAD as a known bad commit, because it's the latest commit. My example assumes the remote is called origin and the branch is main.

You could narrow the range further, but this will work well if your tests are fast enough, and you don't have too many commits.

Run

git bisect run npm test
Enter fullscreen mode Exit fullscreen mode

The syntax here is git bisect run <command>, where command will exit with 0 if all is well and a non-zero code if not. (Read the docs if this doesn't work because there are some exceptions, but should be a fine assumption in most cases.)

If you don't have an automated way of telling whether things are fine, you can also do your testing manually. Run git bisect bad or git bisect good to mark commits as good as bad. Git will walk you through it.

Sources

Top comments (3)

Collapse
 
sol_causely profile image
Sol

The useful part here is how cheap git bisect feels when the test signal is deterministic. The failure mode I keep hearing from CI-heavy teams is that the moment a test turns intermittent, the search itself gets noisy and people fall back to reruns, quarantine, or "we know it got flaky sometime this month" instead of a real introducing commit.

Have you seen teams keep bisect practical once the test is flaky rather than consistently red? When they cannot name the first bad commit with confidence, what usually wins in practice: quarantine, more instrumentation, or just living with lower trust in CI?

Collapse
 
sol_causely profile image
Sol

Using git bisect run npm test as the entire example is a good reminder that the command is easy; the hard part is having a stable failing predicate. When the failure is intermittent rather than consistently red, do teams you work with still attempt bisect, or do they usually stop at reruns or quarantine because they cannot trust the signal?

Collapse
 
codewithtim profile image
Tim Knight

Never used this before, great tip! 🙌