User:Mrjbarker/sandbox

Trunk Based Development (TBD) is a branching model for software development. The Trunk can also referred to as the “mainline” or "master" branch. A simple definition of Trunk Based Development is: "A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after."

- Paul Hammant However, branches can exist for certain scenarios:
 * Short-lived feature branches are used for code-review and build checking (CI), but not artifact creation or publication
 * Release branches are cut from the trunk on a just-in-time basis, are correctly versioned before a release, and usually removed some time after release

Trunk
"Trunk" means the default development branch in a Version Control System (VCS). It’s the base of a project, where all changes are merged together. The default in Git is the master branch.

Feature branch
A feature branch has a clear & focused purpose: to add specific functionality to a project. It shouldn’t contain any other changes for separate features, bug fixes, or code refactoring. The shorter lived the feature branches are, the closer you get to true trunk based development.

Release branch
TBD teams may make a release branch on a just in time basis before a software release. This becomes a stable branch, given that developers are still adding further commits into the trunk. Release branches are not merged back in to the trunk after a software release, they are removed instead.

Principles
The core principles behind TBD are :
 * The trunk is a single integration point which is used for continuous integration and delivery
 * The trunk is always stable, but it can have unfinished features covered by feature toggles

Continuous Integration
TBD enables Continuous Integration (CI) - developers can integrate their work quickly and easily. By integrating regularly, you can detect errors quickly, and locate them more easily. Small incremental changes lead to smaller and less frequent merge conflicts. There are no reasons to hold back on refactoring anymore.

Continuous Delivery
Puppet Labs’ 2015 State of DevOps report talks about how higher performing teams use Continuous Delivery (CD) practices to avoid deployment pain, specifically using trunk-based development as a performance indicator. The Continuous Delivery book also states: "developing on mainline ... is an extremely effective way of developing, and the only one which enables you to perform continuous integration."

- Jez Humble and David Farley

Continuous Feedback
TBD also enables continuous code review - the idea that instead of reviewing large pieces of code infrequently you do it often, painlessly, and share understanding. In an environment where pair programming isn't used, code reviews can form an alternative. "In the end, I don't think it's a matter of picking one over the other so much as ensuring you have more than one pair of eyes looking at the code you've written, however you choose to do it."

- Jeff Atwood