Ask HN: What's your experience of working with git flow?
What's your experience of working with git flow and similar approaches to branching which assume long living (i.e. days or weeks not hours) branches?
Personally, I am quite skeptical about them
- It makes you less agile, it makes experimentation-feedback cycle longer (especially if you have set up continuous deployment process).
- It complicates continuous integration (requires special support from CI server).
- The longer living branch is, the more time you spend merging.
However, I like being able to write good commit documentation, rearrange/merge commits, however, it seems not to worth it for me.
2 comments
[ 2.9 ms ] story [ 21.0 ms ] threadhttp://scottchacon.com/2011/08/31/github-flow.html
If you break projects into small iterations made up of independent effort and continuously integrate feature branches, you should be able to get away with few long-living branches, and you can rebase the ones that you do have from their upstreams frequently enough that they don't get to where you need to expend lots of merge effort when they're ready to ship.
With gitflow, we were eating lots of effort merging caused by hotfixes. Hotfixes would have to get merged into every branch lest you risk regressing them, no rebasing of development on master (for good reason when there's so many people merging into it), people would forget - and the git extension would only do some of the required merges, so before I showed up the team had a spider's web of merges where changes would get lost and hotfixes regress.
If you must have a stable and active branches, gitflow is fine, but make sure everyone really understands git and what they are doing with it (using the gitflow extension prevents this in my experience), do your due diligence and avoid changes on the stable branch like the plague.