Git, Mercurial and other source control tools provide robust and easy to use branching capabilities. For work with OpenSource software —where anyone could be a contributor and the environment is low trust— the use of branches is useful. For modern Agile teams attempting to continually improve (refactor) the code and use tools like Continuous Integration, Continuous Delivery etc, long-lived (> 1 day) branches just add overhead. If you’ve ever experienced merge hell, you know the problem. If you’ve delayed a refactoring because it would make the branch harder to merge, your code has suffered. The long-lived feature branching strategy became popular under the name “GitFlow”, which even Atlassian (not known for being leading edge) says, “Gitflow has fallen in popularity in favor of trunk-based workflows, which are now considered best practices for modern continuous software development and DevOps practices.”
Some organizations “solve” this problem by banning refactoring. (Not kidding, I’ve seen this and its effects).
Others move to a model called Trunk-Based Development, where all code is merged directly back to the Trunk every time a change is “committed”. In a world with Trunk-Based development, all work is done on the main branch or trunk. Team members (or, even better, Pairs) commit their work multiple times a day. This avoids merge hell and makes refactoring less painful.
Some teams in the Trunk Based model, use micro-branches, that live only for one day. Even day long branches increase risk.
Resource Links:
- Branch by Abstraction for dealing with the few complexities that crop up with working off of Trunk
- Branching by an abstraction in the trunk instead of branching via Source Control
- Continuous Integration and Feature Branching
- Patterns for Managing Source Code Branches By Martin Fowler. This is the deepest single article on the subject
- Long running branches — Why are we still doing this?
- Perceived Barriers to Trunk Based Development
- Scaling Trunk Based Development
- Trunk Based Development a summary
- Trunk Based Development as a Cornerstone for Continuous Delivery
- Version Control and Branch Management (from the book Software Engineering at Google)
- Why Google stores billions of lines of code in a single repository
- Why your team doesn’t need to use pull requests
- TrunkBasedDevelopment.com – a whole website devoted to the ins and outs
EXAMPLE FROM REAL WORLD:
Books:
- Trunk-Based Development And Branch By Abstraction – Paul Hammant
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
*Thank you for visiting the World's Largest Opinionated Agile Reference Library. This content is created and the links are curated through the lens of Agile Pain Relief Consulting's view of what is effective in the practice of Scrum and Agile. We don't accept submissions and emails to that effect are marked as spam. Book listings may use affiliate links that could result in a small commission received by us if you purchase, but they do not affect the price at all. From experience, this won't amount to anything more than a cup of coffee in a year.« Back to Glossary Index