Stash, cherry-pick & bisect

These three commands are not daily essentials, but when you need them they save hours. Each solves a specific, very common situation.

git stash: park work in progress

You are halfway through a feature when your manager says production billing is broken. Your changes are not ready to commit, and you need a clean working tree to switch branches.

git stash push -m "wip: sweets inventory filters"   # save and clean the working tree
git switch main
# ...fix the bug, commit, push...
git switch feature/inventory
git stash list                     # stash@{0}: On feature/inventory: wip: sweets inventory filters
git stash pop                      # re-apply and remove from the stash list

Command	Effect
git stash -u	Also stash untracked (new) files
git stash apply stash@{1}	Re-apply but keep it in the list
git stash show -p stash@{0}	View the stashed diff
git stash drop stash@{0}	Delete one stash
git stash branch new-branch	Create a branch from a stash (useful if pop conflicts)

Stashes are local and easy to forget; do not use them as long-term storage. A WIP commit on a branch is often safer.

git cherry-pick: copy one commit

A bug fix was committed on develop, but the release branch needs it now without pulling in every other change.

git switch release/2.3
git cherry-pick 4b7d91e            # applies that commit's changes as a new commit here
git cherry-pick -x 4b7d91e         # same, and records "cherry picked from commit ..." in the message

If there is a conflict, resolve it, git add the files and run git cherry-pick --continue (or --abort). You can pick a range with git cherry-pick A..B, which applies the commits after A up to and including B.

Cherry-picking duplicates commits (new hashes, same change), so use it for targeted fixes, not as a substitute for merging branches.

git bisect: find the commit that broke it

The GST total was correct in v2.1.0 and is wrong today, with 200 commits in between. Bisect performs a binary search, so 200 commits need only about 8 tests.

git bisect start
git bisect bad                     # current commit is broken
git bisect good v2.1.0             # this tag was fine
# Git checks out a middle commit. Test it, then tell Git:
git bisect good                    # or: git bisect bad
# ...repeat until Git prints "<sha> is the first bad commit"
git bisect reset                   # return to where you started

Even better, automate it with a script that exits 0 for good and non-zero for bad:

git bisect start HEAD v2.1.0
git bisect run python manage.py test billing.tests.test_gst_total
git bisect reset

Bisect works best when every commit builds and passes tests, another reason to keep commits small and complete.

Key takeaways

• Stash for short interruptions; commit for anything longer.
• Cherry-pick a specific fix across branches, preferably with -x for traceability.
• Bisect turns "something broke somewhere" into the exact commit in a few steps.