Day 25: Interactive rebase, stash, bisect, cherry-pick
Interactive rebase: rewriting your own history before sharing it
git rebase -i lets you squash messy work-in-progress commits into clean, reviewable ones, reorder them, or edit commit messages — before you push. This is what turns "wip", "fix typo", "actually fix it" into one coherent commit a reviewer can understand.
git rebase -i HEAD~3
# in the editor: change "pick" to "squash" (or "s") on the commits to merge into the one aboveStash
git stash shelves uncommitted changes so you can switch branches cleanly (say, to handle an urgent hotfix), then bring them back later with git stash pop.
Bisect
git bisect binary-searches your commit history to find exactly which commit introduced a bug — you mark one commit "good" and one "bad", and Git checks out commits in between, halving the search space each time you answer good/bad, turning a search through hundreds of commits into ~8-10 steps.
Cherry-pick
git cherry-pick <commit> applies one specific commit from another branch onto your current branch — useful for porting a single fix to a release branch without merging everything else.
git bisect start
git bisect bad # current commit is broken
git bisect good v1.2.0 # this old tag was known good
# Git checks out a midpoint commit — test it, then:
git bisect good # or: git bisect bad
# repeat until Git names the exact culprit commit
git bisect resetKey terms
- Interactive rebase
- Rewriting, squashing, or reordering your own commits before sharing them.
- git bisect
- Binary search over commit history to find the exact commit that introduced a bug.
- Cherry-pick
- Applying one specific commit from elsewhere onto the current branch.
Why does git bisect find a bug in ~10 steps even across 1,000 commits?
