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 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.
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.
EXAMPLE FROM REAL WORLD:
- Trunk-Based Development And Branch By Abstraction – Paul Hammant
*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.