Git stash

At this point you're free to make changes, create new commits, switch branches, and perform any other Git operations; then come back and re-apply your stash when you're ready.

Note that the stash is local to your Git repository; stashes are not transferred to the server when you push.

You can reapply previously stashed changes with git stash pop:

Popping your stash removes the changes from your stash and reapplies them to your working copy.

Alternatively, you can reapply the changes to your working copy and keep them in your stash with git stash apply:

This is useful if you want to apply the same stashed changes to multiple branches.

Now that you know the basics of stashing, there is one caveat with git stash you need to be aware of: by default Git won't stash changes made to untracked or ignored files.

Adding the -u option (or --include-untracked) tells git stash to also stash your untracked files:

You can include changes to ignored files as well by passing the -a option (or --all) when running git stash.

To provide a bit more context, it's good practice to annotate your stashes with a description, using git stash save "message":

By default, git stash pop will re-apply the most recently created stash: stash@{0}

You can choose which stash to re-apply by passing its identifier as the last argument, for example:

Or pass the -p option (or --patch) to view the full diff of a stash:

You can hit ? for a full list of hunk commands. Commonly useful ones are:

There is no explicit "abort" command, but hitting CTRL-C(SIGINT) will abort the stash process.

This checks out a new branch based on the commit that you created your stash from, and then pops your stashed changes onto it.

Or you can delete all of your stashes with:

Depending on what you stashed, a single git stash operation creates either two or three new commits. The commits in the diagram above are:

• stash@{0}, a new commit to store the tracked files that were in your working copy when you ran git stash
• stash@{0}'s first parent, the pre-existing commit that was at HEAD when you ran git stash
• stash@{0}'s second parent, a new commit representing the index when you ran git stash
• stash@{0}'s third parent, a new commit representing untracked files that were in your working copy when you ran git stash. This third parent only created if:
  • your working copy actually contained untracked files; and
  • you specified the --include-untracked or --all option when invoked git stash.

How git stash encodes your worktree and index as commits:

• Before stashing, your worktree may contain changes to tracked files, untracked files, and ignored files. Some of these changes may also be staged in the index.

• Invoking git stash encodes any changes to tracked files as two new commits in your DAG: one for unstaged changes, and one for changes staged in the index. The special refs/stash ref is updated to point to them.

• Using the --include-untracked option also encodes any changes to untracked files as an additional commit.

• Using the --all option includes changes to any ignored files alongside changes to untracked files in the same commit.

When you run git stash pop, the changes from the commits above are used to update your working copy and index, and the stash reflog is shuffled to remove the popped commit. Note that the popped commits aren't immediately deleted, but do become candidates for future garbage collection.