Trunk Based Development

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.