Compare git stash pop and git stash apply for file restores
When developers pull a stored snapshot from the git stash, they can use either the pop or apply option. But which one should you choose? The choice between git stash pop versus apply really boils down to how long you want to keep the banked changes.
How git stash pop and apply differ
The key difference between git stash pop and apply involves the stash history. When a developer uses the git stash apply command, the most recently saved stash overwrites files in the current working tree but leaves the stash history alone. In contrast, the pop command restores files but then deletes the applied stash. If a developer ever feels the need to use that restored stash again, it will be saved in the local file system.
Think of the git stash pop command as a two-step process. It pulls the most recent stash from history, makes the appropriate changes to files in the local workspace and then deletes that entry from the stash history. Once the git stash pop command is successfully invoked, the stash is permanently deleted and can never be accessed again.
Git stash pop and drop
In more technical terms, the git stash pop command is a combination of git stash apply and git stash drop. If the apply and drop commands are invoked separately, the result is identical if the git stash pop command was invoked.
How does a git stash pop conflict affect code?
One of the finer details of git stash pop is that it must run successfully for the drop operation to occur. If a developer modifies workspace files in such a way that a git stash pop conflict arises, the pop behaves exactly like the git stash apply command. The user then has two choices. They can either resolve the git stash pop conflict, or they can discard the changes and continue, knowing that all the stashed code is still stored on the local file system for future reference.
No-conflict git stash pop example
In the following example we will:
- Initialize a Git repository;
- Add a file;
- Perform a commit;
- Edit the file;
- Stash it; and
- Use the git stash pop command to restore the stashed file.
Notice that the git stash list command issued after the pop indicates that there is no stash history. The popped stash has been deleted.
/examples/git-stash-pop
$ git init
$ echo "git stash pop and apply" >> stash-pop.html
$ git add .
$ git commit -m "git stash pop example"
$ echo "no git stash pop conflict" >> stash-pop.html
$ git stash
$ git stash list
stash@{0}: WIP master: a6d5913 git stash pop example
$ git stash pop
$ git stash list
no git stash history to show
$ git reflog
a6d5913 HEAD@{0}: reset: moving to HEAD
a6d5913 HEAD@{1}: commit: git stash pop example
No-conflict git stash apply example
This git stash apply example follows the exact same path as the pop example above, but when the stash history is listed, the applied stash is still there. This is the fundamental difference between the two commands.
/examples/git-stash-apply
$ git init
$ echo "git stash apply and pop" >> stash-apply.html
$ git add .
$ git commit -m "git stash apply example"
$ echo "no git stash apply conflict" >> stash-apply.html
$ git stash
$ git stash list
stash@{0}: WIP master: c112505 git stash apply example
$ git stash apply
$ git stash list
stash@{0}: WIP master: c112505 git stash apply example
Git stash pop and apply best practices
Developers shouldn't shelve Git changes in the stash too often. Use the stash for temporary, short-term storage of file system changes. If changes must be stored over a prolonged period, commit those changes to a topic branch.
As such, the idea of a keeping a local stash around for an extended time runs counter to the basic philosophy of distributed version control with Git. That's why it's recommended that a developer use git stash pop to restore conflict-free files instead of the complementary git stash apply command.