In a previous Git question, Daniel Benamy was talking about a workflow in Git:
I was working on master and committed some stuff and then decided I wanted to put that work on hold. I backed up a few commits and then branched from before I started my crap work.
He wanted to restore his working state to a previous point in time without losing his current changes. All of the answers revolved around, in various ways, something like
git branch -m master crap_work git branch -m previous_master master
How does this compare to git stash
? I'm a bit confused trying to see what the different use case here when it seems like everything git stash
does is already handled by branching…
@Jordi Bunster: Thanks, that clears things up. I guess I'd kind of consider "stashing" to be like a lightweight, nameless, branch. So anything stash can do, branch can as well but with more words. Nice!
Git stash branch <name> This command creates a new branch with the latest stash, and then deletes the latest stash ( like stash pop). If you need a particular stash you can specify the stash id. This will be useful when you run into conflicts after you've applied the stash to the latest version of your branch.
The git commit and git stash commands are similar in that both take a snapshot of modified files in the git working tree and store that snapshot for future reference. The key differences between the two are as follows: A commit is part of the public git history; a stash is stored locally.
The git stash command takes your uncommitted changes (both staged and unstaged), saves them away for later use, and then reverts them from your working copy. For example: $ git status On branch main Changes to be committed: new file: style. css Changes not staged for commit: modified: index.
Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.
'stash' takes the uncommitted, "dirty" stuff on your working copy, and stashes it away, leaving you with a clean working copy.
It doesn't really branch at all. You can then apply the stash on top of any other branch. Or, as of Git 1.6, you can do:
git stash branch <branchname> [<stash>]
to apply the stash on top of a new branch, all in one command.
So, stash works great if you have not committed to the "wrong" branch yet.
If you've already committed, then the workflow you describe in your question is a better alternative. And by the way, you're right: Git is very flexible, and with that flexibility comes overlapping functionality.
When you restore your stash, your changes are reapplied and you continue working on your code.
To stash your current changes
$ git stash save Saved "WIP on master: e71813e..."
You can also have more than one stash. The stash works like a stack. Every time you save a new stash, it's put on top of the stack.
$ git stash list stash@{0}: WIP on master: e71813e..."
Note the stash@{0}
part? That's your stash ID. You'll need it to restore it later on. Let's do that right now. The stash ID changes with every stash you make. stash@{0} refers to the last stash you made.
To apply a stash
$ git stash apply stash@{0}
You may notice the stash is still there after you have applied it. You can drop it if you don't need it any more.
$ git stash drop stash@{0}
Or, because the stash acts like a stack, you can pop off the last stash you saved:
$ git stash pop
If you want to wipe all your stashes away, run the 'clear' command:
$ git stash clear
It may very well be that you don't use stashes that often. If you just want to quickly stash your changes to restore them later, you can leave out the stash ID.
$ git stash ... $ git stash pop
Feel free to experiment with the stash before using it on some really important work.
I also have a more in-depth version of this posted on my blog.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With