I've recently been looking at how me and my team uses Git and how our workflows work. We currently use a feature-branch workflow which seems to work well.
I've also seen some individuals on our team use workflow based on git stash. The workflow goes something like this:
- Work on a main branch (like
master
) - Make commits as you go
- If you need to get changes or switch branches, push your uncommitted changes onto the stash
- Once your updating is done, pop the changes off the stash.
I should mention that this workflow is used instead of a feature branch workflow. Instead of taking a branch and working on it, developers here only ever work on a single branch and push/pop off the stack as they see fit.
I actually don't think this is a great workflow, and branching would be more appropriate than using git stash in this way. I can see the value of git stash as an emergency operation, but not for using it in a daily, regular workflow.
Would using git stash regularly be considered an anti-pattern? If so, what are some specific problems that could arise? If not, what are the benefits?
Best Answer
From the Git SCM Book:
Given this description, I would say this is an Anti Pattern. An overly simplified explanation of Git Stash would be that it is the "Cut and Paste" of source control. You take a bunch of changed files, "stash" them away in a holding pen outside of Git's normal branching workflow, and then reapply those changes to a different branch at a later date.
Going back a little further, committing to master is the anti pattern here. Use branches. That's what they were designed for.
It really boils down to this:
You can hammer a screw into the wall and it will hold up a picture, but using a screwdriver is what you should do. Don't use a hammer when the screwdriver is sitting right beside you.
About Committing "Broken" Code
While the following is opinion, I have come to this opinion from experience.
Commit early, and commit often. Commit as much broken code as you want. View your local commit history as "save points" while you hack away at something. Once you've done a logical piece of work, make a commit. Sure it might break everything, but that doesn't matter as long as you don't push those commits. Before pushing, rebase and squash your commits.
For the OP, this Linux kernal message thread might be of interest, because it kind of sounds like some members of the OP's team is using Git in a similar manner.
@RibaldEddie said in a comment below:
(at the risk of incurring the wrath of many people)
Linus said:
What I think @RibaldEddie is trying to say is that you can use
git stash
in a feature branch workflow -- and this is true. It's not the use ofgit stash
that is the problem. It is the combination of committing to master and usinggit stash
. This is an anti pattern.Clarifying
git rebase
From @RibaldEddie's comment:
(Emphasis mine)
Modifying commit history is not a bad thing, as long as it is local commit history. If you rebase commits that you've already pushed, you'll essentially orphan anyone else using your branch. This is bad.
Now, say you've made several commits during the course of a day. Some commits were good. Some... not so good. The
git rebase
command in conjunction with squashing your commits is a good way to clean up your local commit history. It's nice to merge in one commit to public branches because it keeps the commit history of your team's shared branches clean. After rebasing, you'll want to test again, but if tests pass then you can push one clean commit instead of several dirty ones.There is another interesting Linux Kernel thread on clean commit history.
Again, from Linus:
(emphasis mine)
Conclusion
In the end, the OP has some developers doing this:
There are two problems here:
git stash
andgit pull
on master when they should be using feature branches.There is nothing wrong with using
git stash
-- especially before a pull -- but usinggit stash
in this manner is an anti pattern when there are better workflows in Git.Their use of
git stash
a red herring. It is not the problem. Committing to master is the problem.