Stash and Cherry-pick

Stash: put work aside

You’re in the middle of something, files half-edited, and you need to switch branches, pull, or try something on a clean copy. You don’t want to commit half-done work. git stash saves your changes, both staged and unstaged edits to tracked files, onto a stack, and resets your working directory to the last commit ¹:

me@linuxbox:~/garden$ git status -s
 M beds.txt
me@linuxbox:~/garden$ git stash push -m "rotation idea"
Saved working directory and index state On main: rotation idea
me@linuxbox:~/garden$ git status -s
me@linuxbox:~/garden$

Clean. Switch branches, pull, fix the other thing, and come back. Plain git stash does the same as git stash push, with an automatic label like WIP on main: f8509eb Add garlic and squash; -m gives it a label you’ll recognize later. (Older tutorials use git stash save, which push replaces ¹.)

Getting it back

The stash is a list, newest first. Each entry has a name: stash@{0} is the latest, stash@{1} the one before, and so on ²:

me@linuxbox:~/garden$ git stash list
stash@{0}: On main: rotation idea
me@linuxbox:~/garden$ git stash show -p
diff --git a/beds.txt b/beds.txt
index 99dea17..e6c35f7 100644
--- a/beds.txt
+++ b/beds.txt
@@ -2,3 +2,4 @@
 beans
 garlic
 squash
+half-done: rotate the beans

git stash show -p shows a stash as a diff before you use it. To bring it back, git stash pop reapplies it and then removes it from the list:

me@linuxbox:~/garden$ git stash pop
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   beds.txt

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (5b18bae622167b7631292d9628118f1c5d4a6903)

The others ^{2 1}:

• git stash apply reapplies but keeps the stash in the list, for using the same changes on more than one branch. git stash drop then removes it.
• git stash pop stash@{2} (or apply) picks an older one.
• --index restores what was staged as staged; without it, everything comes back unstaged.
• git stash branch new-name makes a new branch at the commit you stashed from and applies the stash there. Use it when main has moved on and the stash no longer applies cleanly.

You can apply a stash on a different branch from the one you saved it on. If the changes clash with what’s there, you get ordinary merge conflicts. When pop hits a conflict, it keeps the stash, so nothing is lost: resolve the conflict, then git stash drop yourself ².

Stashes are meant for minutes or hours, not weeks. A long-lived stash is easy to forget; if work is worth keeping, commit it on a branch.

What stash leaves behind

By default, stash only takes files git already tracks. New, untracked files stay where they are ¹:

me@linuxbox:~/garden$ git status -s
 M beds.txt
?? todo.txt
me@linuxbox:~/garden$ git stash
Saved working directory and index state WIP on main: f8509eb Add garlic and squash
me@linuxbox:~/garden$ git status -s
?? todo.txt

Add -u (--include-untracked) to stash them too, and -a (--all) to include ignored files as well ¹:

me@linuxbox:~/garden$ git stash -u
Saved working directory and index state WIP on main: f8509eb Add garlic and squash
me@linuxbox:~/garden$ git status -s
me@linuxbox:~/garden$

Cleaning up untracked files

To get rid of untracked files instead of saving them, there’s git clean. It deletes files that were never committed, so git can’t bring them back, and Pro Git warns there’s often no retrieving them ¹. Always look first with -n (dry run), then do it with -f (force), which git requires by default ³:

me@linuxbox:~/garden$ git clean -n
Would remove todo.txt
me@linuxbox:~/garden$ git clean -f
Removing todo.txt

Add -d to remove untracked directories too, and -x to also remove files your .gitignore covers, such as build output ³. git clean -i asks about each file. If you’re not sure, git stash --all clears everything out but keeps a copy ¹.

Cherry-pick: copy one commit

Sometimes you want just one commit from another branch, not the whole branch. Here the experiment branch has a useful fix and an experiment you don’t want on main:

me@linuxbox:~/garden$ git log --oneline main..experiment
ef19e9f Try purple carrots
8be2f4a Fix bean spacing

(main..experiment means “commits on experiment that aren’t on main” ¹.) git cherry-pick takes the change a commit introduced and applies it to your current branch as a new commit ⁴:

me@linuxbox:~/garden$ git switch main
Switched to branch 'main'
me@linuxbox:~/garden$ git cherry-pick 8be2f4a
[main 506193c] Fix bean spacing
 Date: Mon Oct 5 09:06:00 2026 -0500
 1 file changed, 1 insertion(+)
 create mode 100644 spacing.txt
me@linuxbox:~/garden$ git log --oneline --graph --all --decorate
* 506193c (HEAD -> main) Fix bean spacing
| * ef19e9f (experiment) Try purple carrots
| * 8be2f4a Fix bean spacing
|/
* f8509eb Add garlic and squash
* d832160 Add beans
* e31a769 Plan the beds

The copy has the same message, author, and date as the original but a new ID, because its parent is different (module 3). experiment is unchanged. You can give several commits at once, and they’re applied in order ⁴.

Typical uses: rescuing one good commit from an abandoned branch, or bringing a fix from one branch to another without merging everything else. Since cherry-pick copies rather than moves, if you later merge the whole branch, history holds the same change twice, in two commits. Use it for single commits, not instead of merging.

When copying between branches other people use, such as backporting a fix to an older release branch, -x adds a line (cherry picked from commit ...) to the message. The git docs advise leaving it off when you pick from your own private branch, since nobody else can see that commit ⁴.

When a cherry-pick conflicts

Cherry-pick needs a clean working tree to start ⁴. If the change doesn’t apply cleanly, it stops with conflict markers, just like a merge:

me@linuxbox:~/garden$ git cherry-pick experiment
Auto-merging beds.txt
CONFLICT (content): Merge conflict in beds.txt
error: could not apply ef19e9f... Try purple carrots
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".
hint: You can instead skip this commit with "git cherry-pick --skip".
hint: To abort and get back to the state before "git cherry-pick",
hint: run "git cherry-pick --abort".
hint: Disable this message with "git config set advice.mergeConflict false"

Same routine as merging and rebasing (module 3): fix the file, git add it, and git cherry-pick --continue; or git cherry-pick --abort to put everything back ⁴. (git cherry-pick experiment picks the commit at the tip of that branch.)

Your turn

So

git stash (or git stash push -m "label") shelves unfinished changes to tracked files and leaves your working directory clean; -u includes untracked files. git stash list and show -p show what’s there, pop brings the newest back and removes it, and apply brings it back and keeps it. git clean deletes untracked files for good, so run -n before -f. git cherry-pick <commit> copies one commit’s change onto your branch as a new commit; conflicts are settled with --continue or --abort, as in a merge.