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!
‘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:
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.