These four commands don't come up every day, but each one solves a specific problem so well that knowing it exists saves real time (or real panic) the first time you need it. This is the last guide in the series - by the end, you'll have the full toolkit, not just the daily-driver commands.
git stash: shelving work without committing it
Sometimes you need to switch branches immediately - a production bug just came in - but you're mid-way through unfinished, uncommitted work that isn't ready to be a real commit yet. git stash takes all your uncommitted changes and tucks them away, leaving your working directory clean. Switch branches, fix the bug, come back, and git stash pop brings your shelved changes back exactly as they were.
| Command | What it does |
|---|---|
git stash | Shelves current uncommitted changes |
git stash list | Shows everything currently stashed |
git stash pop | Reapplies the most recent stash and removes it from the list |
git stash apply | Reapplies the most recent stash but keeps it in the list too |
git stash drop | Deletes a stash without applying it |
git cherry-pick: taking one commit without the rest
git cherry-pick <commit-hash> applies the changes from one specific commit onto your current branch, without bringing along everything else on the branch it came from. The classic use case: a critical fix landed on a feature branch that isn't ready to merge yet, but production needs that one fix right now. Cherry-pick it straight onto main, ship it, and the feature branch can still merge normally later.
git bisect: finding exactly which commit broke something
When a bug exists now but didn't exist a hundred commits ago, manually checking out commits one at a time to find the culprit is painfully slow. git bisect automates a binary search through history instead: tell it a known-good commit and a known-bad one, and it checks out the midpoint for you to test. You mark each one git bisect good or git bisect bad, and it narrows the range by half each time - turning what could be dozens of manual checks into roughly log2(n) of them. If you have an automated test that can detect the bug, git bisect run <test-script> does the entire search unattended.
git reflog: the safety net for "I think I just lost my work"
Git keeps a local log, separate from your regular commit history, of every place HEAD and your branches have pointed - every commit, checkout, reset, and rebase. git reflog shows this log, and it's often the way back from a mistake that looks unrecoverable: a bad reset --hard, a rebase that went wrong, a branch you deleted by accident. Find the entry just before things went wrong, then git checkout <that-hash> or git reset --hard <that-hash> to get back to it.
Where this leaves you
Between this series and genuine hands-on practice, you now have the core workflow, branching and merging, remotes, conflict resolution, the three ways to undo something, rebase vs. merge, team workflows, and this guide's four recovery and surgical-editing tools. That covers the overwhelming majority of what comes up in real projects - the rest tends to be learned the way most Git knowledge actually gets learned: by hitting a specific problem and looking up the one command that solves it.