6 ms·

A successful Git branching model (2010)

61 points by dutchbrit 13y ago

programminggeek 13y ago
I'm pretty sure git flow has been posted to HN many times. How is this on the front page?
- ianstallings 13y ago
  Agreed. Might as well mention the tool while we're here: https://github.com/nvie/gitflow https://github.com/nvie/gitflow I did just enter a shop where git is new to a lot of people. Kind of blew my mind but I've been in startup land for years and just came back to enterprise development.
- Flenser 13y ago
  Yup, see this summary from 623 days ago: https://news.ycombinator.com/item?id=3446367 https://news.ycombinator.com/item?id=3446367
- dutchbrit 13y ago
  I'm still happy I posted this however, the comments on this subject inside this thread so far are pretty useful.
Alan01252 13y ago
We've just started using this where I'm currently working, and it definitely makes a lot of sense. There's a command line tool which helps you keep to this branching model. Available here. https://github.com/nvie/gitflow https://github.com/nvie/gitflow Unfortunately it seems to of been abandoned by the author. A more active fork is available here https://github.com/petervanderdoes/gitflow https://github.com/petervanderdoes/gitflow Note that if installing on Ubuntu using apt, you'll get the no longer maintained version. This cheat sheet helped me get up and flowing fast. http://danielkummer.github.io/git-flow-cheatsheet/ http://danielkummer.github.io/git-flow-cheatsheet/
kstop 13y ago
Article mentions wanting to disable fast-forward merges. This should do it (in newer versions of git): $ git config --global --add merge.ff false
gabrtv 13y ago
With http://deis.io/ http://deis.io/ we tried GitFlow as well as HubFlow (http://datasift.github.io/gitflow/ http://datasift.github.io/gitflow/) which adds better GitHub integration. After a few release cycles, we decided to switch back to simple feature branches with a master that is always deployable.. modeled after GitHub's workflow: http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html We found GitFlow's benefits weren't enough to compensate for the added complexity and subpar GitHub integration.
sonnym 13y ago
Over time, I have come to feel this git workflow is more of an attempt to coerce git into a workflow that is familiar to users coming from subversion, rather than learning and understanding git's strengths. A corollary problems is that it mixes development workflow with release management - two disparate concerns that should be handled separately. After a couple years of using this model, I have done away with using a develop or release branches whatsoever. Develop everything in feature branches, based on either the most recent production tag or the master branch, depending on if it is a hotfix or if it is new development work. A lot of people do not seem to understand you can just checkout a tag, so you do not need to keep a number of hotfix branches around for in-house repositories. Now, it would be nice to develop a better tagging strategy for rolling updates to a web application, but, for the time being, simply using a stage and production tag work well enough. This is certainly suboptimal and can cause problems, and I cannot recommend doing so. Instead, use production and stage tags with either sane version numbers or simple timestamps. It would be best to only promote from staging to production, but that is not exactly necessary. Most of my thoughts on the release management side of things comes from Alex at The Daily WTF [1]. 1. http://thedailywtf.com/Articles/Release-Management-Done-Right.aspx http://thedailywtf.com/Articles/Release-Management-Done-Righ...
- dustingetz 13y ago
  umm, how big is your codebase? The OP describes more or less the way Linux uses git.
  - sonnym 13y ago
    I am working on average size web applications, which simplifies things greatly, but I do not think your characterization of kernel development is correct. The official kernel mirror on github[1] does not have any of these extraneous branches, and, unsurprisingly, makes good use of the tagging ability built into git. In fact, the kernel developers prefer[2,3] that feature branches are always based on a known working state if possible, rather than some arbitrarily moving branch, be it called master or develop. That said, the master branch of the linux kernel is, by no means, relegated to only having merge commits from feature branches that correspond to releases. 1. https://github.com/torvalds/linux https://github.com/torvalds/linux 2. http://lwn.net/Articles/328436/ http://lwn.net/Articles/328436/ 3. http://lwn.net/Articles/328438/ http://lwn.net/Articles/328438/
ams6110 13y ago
Quite honestly, that workflow looks just as complicated as anything I've seen with svn.
- jlgreco 13y ago
  The idea isn't to be simpler than SVN, the idea is to be more flexible than SVN. I don't follow 'git flow', but git is flexible enough to allow you to develop your own style. Nothing is pressed on you.
EToS 13y ago
Sourcetree by atlassian seems to handle git flow really well. http://www.sourcetreeapp.com/ http://www.sourcetreeapp.com/
Aldo_MX 13y ago
I have tried gitflow in the past... too much for my needs, I only need the feature/hotfix branches and the master branch.

61 points by dutchbrit 13y ago

programminggeek 13y ago

I'm pretty sure git flow has been posted to HN many times. How is this on the front page?

ianstallings 13y ago
Agreed. Might as well mention the tool while we're here: https://github.com/nvie/gitflow https://github.com/nvie/gitflow I did just enter a shop where git is new to a lot of people. Kind of blew my mind but I've been in startup land for years and just came back to enterprise development.
Flenser 13y ago
Yup, see this summary from 623 days ago: https://news.ycombinator.com/item?id=3446367 https://news.ycombinator.com/item?id=3446367
dutchbrit 13y ago
I'm still happy I posted this however, the comments on this subject inside this thread so far are pretty useful.

Alan01252 13y ago

We've just started using this where I'm currently working, and it definitely makes a lot of sense. There's a command line tool which helps you keep to this branching model. Available here. https://github.com/nvie/gitflow https://github.com/nvie/gitflow Unfortunately it seems to of been abandoned by the author. A more active fork is available here https://github.com/petervanderdoes/gitflow https://github.com/petervanderdoes/gitflow Note that if installing on Ubuntu using apt, you'll get the no longer maintained version. This cheat sheet helped me get up and flowing fast. http://danielkummer.github.io/git-flow-cheatsheet/ http://danielkummer.github.io/git-flow-cheatsheet/

kstop 13y ago

Article mentions wanting to disable fast-forward merges. This should do it (in newer versions of git): $ git config --global --add merge.ff false

gabrtv 13y ago

With http://deis.io/ http://deis.io/ we tried GitFlow as well as HubFlow (http://datasift.github.io/gitflow/ http://datasift.github.io/gitflow/) which adds better GitHub integration. After a few release cycles, we decided to switch back to simple feature branches with a master that is always deployable.. modeled after GitHub's workflow: http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html We found GitFlow's benefits weren't enough to compensate for the added complexity and subpar GitHub integration.

sonnym 13y ago

Over time, I have come to feel this git workflow is more of an attempt to coerce git into a workflow that is familiar to users coming from subversion, rather than learning and understanding git's strengths. A corollary problems is that it mixes development workflow with release management - two disparate concerns that should be handled separately. After a couple years of using this model, I have done away with using a develop or release branches whatsoever. Develop everything in feature branches, based on either the most recent production tag or the master branch, depending on if it is a hotfix or if it is new development work. A lot of people do not seem to understand you can just checkout a tag, so you do not need to keep a number of hotfix branches around for in-house repositories. Now, it would be nice to develop a better tagging strategy for rolling updates to a web application, but, for the time being, simply using a stage and production tag work well enough. This is certainly suboptimal and can cause problems, and I cannot recommend doing so. Instead, use production and stage tags with either sane version numbers or simple timestamps. It would be best to only promote from staging to production, but that is not exactly necessary. Most of my thoughts on the release management side of things comes from Alex at The Daily WTF [1]. 1. http://thedailywtf.com/Articles/Release-Management-Done-Right.aspx http://thedailywtf.com/Articles/Release-Management-Done-Righ...

dustingetz 13y ago
umm, how big is your codebase? The OP describes more or less the way Linux uses git.
- sonnym 13y ago
  I am working on average size web applications, which simplifies things greatly, but I do not think your characterization of kernel development is correct. The official kernel mirror on github[1] does not have any of these extraneous branches, and, unsurprisingly, makes good use of the tagging ability built into git. In fact, the kernel developers prefer[2,3] that feature branches are always based on a known working state if possible, rather than some arbitrarily moving branch, be it called master or develop. That said, the master branch of the linux kernel is, by no means, relegated to only having merge commits from feature branches that correspond to releases. 1. https://github.com/torvalds/linux https://github.com/torvalds/linux 2. http://lwn.net/Articles/328436/ http://lwn.net/Articles/328436/ 3. http://lwn.net/Articles/328438/ http://lwn.net/Articles/328438/

ams6110 13y ago

Quite honestly, that workflow looks just as complicated as anything I've seen with svn.

jlgreco 13y ago
The idea isn't to be simpler than SVN, the idea is to be more flexible than SVN. I don't follow 'git flow', but git is flexible enough to allow you to develop your own style. Nothing is pressed on you.

EToS 13y ago

Sourcetree by atlassian seems to handle git flow really well. http://www.sourcetreeapp.com/ http://www.sourcetreeapp.com/

Aldo_MX 13y ago

I have tried gitflow in the past... too much for my needs, I only need the feature/hotfix branches and the master branch.