Practical Git techniques for worktrees, bisect, cherry-pick, and interactive rebase.
Key takeaways
The patterns worth keeping
Skim this block if you want the condensed version before reading the full walkthrough below.
Point 01
Git worktrees let you check out multiple branches in separate directories simultaneously.
Point 02
Git bisect uses binary search to find a bug-introducing commit in minutes instead of hours.
Point 03
Cherry-pick applies any commit from any branch to your current branch without a full merge.
Point 04
Named stashes created with git stash push -m stay manageable even when you accumulate several.
Point 05
Interactive rebase lets you squash, reorder, or reword commits before pushing to a shared branch.
Section 01
Use git worktree instead of stashing for context switches
The classic problem: you are mid-feature when production breaks. git stash saves your changes but can ruin node_modules, active dev servers, and anything else that tracks file state. A worktree creates a completely separate directory where you can run a full dev environment without touching your current branch.
The command git worktree add -b emergency-fix ../my-app-fix main creates a new branch in a sibling folder. Push the fix, remove the worktree, and return to your feature branch exactly as you left it.
- Run git worktree add -b hotfix-name ../folder-name main to create a new branch checked out in a separate directory.
- Both directories share the same repository — commits in one are immediately visible from the other.
- Remove the worktree when done with git worktree remove ../folder-name; the branch itself stays intact.
Section 02
Find the exact commit that broke something with git bisect
When a bug exists now but did not exist three weeks ago, the naive approach is manually checking recent commits one by one. git bisect turns that into a binary search, finding the culprit in log2(N) steps instead of N.
On a 200-commit history, that means about 8 steps instead of up to 200. Run git bisect run with a test script to automate it entirely when you have a test that reproduces the bug.
- Run git bisect start, then mark the current broken state with git bisect bad.
- Mark a known-good older commit with git bisect good followed by the commit hash.
- Git checks out the midpoint commit; test it and mark good or bad until Git identifies the offending commit.
Section 03
Apply a specific commit to another branch with cherry-pick
Cherry-pick is most useful when a fix made on main also needs to go into a release branch, or when a commit was made on the wrong branch. Instead of merging the whole branch, you copy only the specific commit you need.
Pass multiple hashes to apply several commits at once, or use git cherry-pick A..B to apply a range. Conflicts resolve the same way as a merge.
- Find the commit hash you want with git log --oneline.
- Run git cherry-pick followed by the hash on the target branch to apply just that commit.
- Cherry-pick creates a new commit with the same changes but a different hash; the original stays on its branch.
Section 04
Name your stashes so you can find them later
The default stash names tell you nothing about what is inside. After accumulating three or four stashes, you have to pop each one speculatively to see what it contains.
Naming stashes with the -m flag solves this immediately. A list showing WIP: auth refactor before DB changes is navigable. One showing stash@{0} through stash@{4} is not.
- Use git stash push -m followed by a description to create a stash with a readable name.
- Run git stash list to see all stashes with their descriptions.
- Apply a specific stash by index with git stash apply stash@{2}.
Section 05
Clean up commits before pushing with interactive rebase
A typical feature branch accumulates WIP, fix typo, and try again commits that have no value in the permanent history. Interactive rebase lets you combine, reorder, or rename them before they become part of the shared record.
The editor shows each commit as a line starting with pick. Change pick to squash to fold a commit into the one above it. Save and close; Git replays the commits in the new order.
- Run git rebase -i HEAD~5 to open an editor with the last five commits listed.
- Mark commits as squash to merge them into the previous one, or reword to edit the message.
- Only use interactive rebase on commits that have not been pushed to a shared branch.