# git bisect: Usage, Options & Common CI Errors

> git bisect binary-searches history to find the commit that introduced a bug. Reference for start, good, bad, run, reset, and automating it in CI.

Source: https://latchkey.dev/learn/command-reference/git-bisect  
Updated: 2026-06-25

git bisect runs a binary search through your history to pinpoint the commit that broke something.

Bisect turns "somewhere in 500 commits" into ~9 checks. With git bisect run it is fully automatable in CI.

## What it does

git bisect checks out commits between a known-good and known-bad point, asking you (or a script) to mark each as good or bad, halving the search range until it finds the first bad commit.

## Common usage

```Terminal
git bisect start
git bisect bad                    # current commit is broken
git bisect good v1.0.0            # this tag was fine
# ... test each checkout, mark good/bad ...
git bisect run ./test.sh          # fully automated
git bisect reset                  # return to original HEAD
```

## Options

| Subcommand | What it does |
| --- | --- |
| start | Begin a bisect session |
| good <rev> / bad <rev> | Mark a commit as working / broken |
| run <cmd> | Auto-bisect using a test script exit code |
| skip | Skip an untestable commit |
| reset | End bisect and restore HEAD |

## Common errors in CI

For git bisect run, the test script must exit 0 for good, 1-124/126/127 for bad, and 125 to skip an untestable commit; a non-conforming exit code derails the search. Always finish with git bisect reset, and ensure full history is present (no shallow clone).

## Using this in CI

CI checkouts are shallow and detached by default, which changes the answer this command gives you. Commands that read history, branch names, or tags need the checkout configured for it.

```.github/workflows/ci.yml
- uses: actions/checkout@v4
  with:
    fetch-depth: 0   # history, tags, and git describe all need this

- run: |
    git rev-parse --is-shallow-repository   # expect false
    git rev-parse --abbrev-ref HEAD          # prints HEAD when detached
```

> `git rev-parse --abbrev-ref HEAD` returns the literal string `HEAD` on a detached checkout rather than a branch name. On GitHub Actions read `github.ref_name` instead; the git command cannot know what it was checked out for.

## FAQ

### git bisect: Usage, Options & Common CI Errors?

Bisect turns "somewhere in 500 commits" into ~9 checks. With git bisect run it is fully automatable in CI.

### What it does?

git bisect checks out commits between a known-good and known-bad point, asking you (or a script) to mark each as good or bad, halving the search range until it finds the first bad commit.

### Common errors in CI?

For git bisect run, the test script must exit 0 for good, 1-124/126/127 for bad, and 125 to skip an untestable commit; a non-conforming exit code derails the search. Always finish with git bisect reset, and ensure full history is present (no shallow clone).

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt