Since a couple of weeks I follow a controversial topic on twitter which I would describe as the “anti-feature-branching” movement. In a previous post I have already written about feature branching and why someone would recommend to not following such a successful branching model.
The solution to many daily problems a typical developer is facing when applying feature branching will be solved by doing Trunk Based Development. If you integrate daily instead of waiting until the complete feature is finished, the merge won’t be a big deal. However, the merge conflict of integrating a completed feature after a few month into mainline could be a big mess. I think that is something every developer has experienced already.
@tdpauw gave a nice talk about “Feature Branching is Evil” on the XP DAY in UKRAINE in November last year (the slides from a similar presentation a few days ago can be found here). The article “On DVCS, continuous integration, and feature branches” also lists some valid arguments against feature branching.
I have used “A successful Git branching model” in several software projects making both positive and negative experiences. The distinction between a master branch for releases and a develop branched used for integration helps you keeping your history clean. However, it works against the idea of being able to deliver at every point of time when applying CI/CD.
Combining your branching strategy with distributed code reviews (e.g. in combination with merge/pull requests) is another practice which helped me and my team members to share a common knowledge about our code base and keep a high software quality level.
However, I experienced more than once that feature branching can easy lead to have multiple long-lived branches which diverge and often end in a merge hell. That’s why I (and my others) recommend to work in small increments and integrate very often to ensure a lifetime of your branches.