Bisect and Cherry-Pick

Git bisect is binary search for bugs — and Claude Code turns it into a semi-automated process. The traditional workflow is manual: you mark a good commit and a bad commit, git checks out the midpoint, you test, you mark it good or bad, repeat. With Claude, the testing step becomes automated. Tell Claude: "Run git bisect. The test is: run npm test and check if the auth module passes. Good commit: abc123. Bad commit: HEAD." Claude runs the bisect, executes the test at each step, marks the result, and identifies the offending commit.

Cherry-picking is simpler but has a subtle trap. Claude can cherry-pick commits by hash without issue. The trap is context: a cherry-picked commit may depend on changes from adjacent commits that were not cherry-picked. Claude resolves the immediate conflicts but cannot always detect missing contextual dependencies. The safest pattern: after cherry-picking, always run the full test suite to verify nothing is broken by the missing context.

1. 1. Automated Bisect Tell Claude the good commit, the bad commit, and the test command. Claude runs git bisect start, marks endpoints, and automates the binary search using git bisect run with your test command. The result: the exact commit that introduced the regression.
2. 2. Safe Cherry-Pick Specify the commit hash and the target branch. After cherry-picking, have Claude run the full test suite to catch missing contextual dependencies. A cherry-pick that compiles but fails tests is worse than no cherry-pick at all.
3. 3. Verify After Both Both bisect and cherry-pick alter your working state. Always verify: git log to confirm history looks correct, npm test to confirm functionality, git diff to confirm no unexpected changes leaked in.