git bisect and cherry-pick: Finding bugs and taking over commits

In short: With git bisect you find by halving the commit that introduced a bug; with git cherry-pick you take over individual commits into another branch.

In more detail: Two advanced Git commands that save a lot of time in everyday work. Both assume that the history is cleanly divided into sensible, small commits.

In Depth

git bisect: bug search by binary search

You know: three weeks ago it worked, now it does not, and 200 commits lie in between. git bisect repeatedly halves the range (binary search), and after about eight steps you know the culprit.

git bisect start
git bisect bad                 # current state is faulty
git bisect good v1.4.0         # this state was fine
# Git checks out a middle commit: test, then
git bisect good                # or: git bisect bad
# ... repeat until "<hash> is the first bad commit"
git bisect reset               # back to the starting state

With a test script it runs automatically: git bisect run npm test (exit code 0 = good, 1 to 127 = bad, 125 = skip).

git cherry-pick: taking over single commits

Normally you merge whole branches. cherry-pick instead copies one or a few commits onto the current branch:

git switch release/1.2
git cherry-pick 3f4a2b1           # take over one commit
git cherry-pick A..B              # a range
git cherry-pick -x 3f4a2b1        # note the source in the message

Typical case: a bug was fixed on the main branch but should also go into the release branch. The picked commit gets a new hash ID because it sits on a different parent.

Conflicts and pitfalls

On conflicts Git stops: resolve the conflict, git add, then git cherry-pick --continue (or --abort). Whoever picks commits repeatedly creates duplicates in the history that can confuse later merges. Cherry-pick does not replace a clean branch workflow. With bisect the tested states must build and be testable; with git bisect skip you skip broken intermediate states.

Connection

Small, clean commits (see Conventional Commits) make both tools effective in the first place: a huge “changed everything” commit can neither be found nor taken over in a targeted way. git blame and git log -S also help in the search.

See also: Git, Git rebase, Merge conflicts, Conventional Commits