🕷️ Crawler Inspector

Trunk Based Development: Introduction  **Trunk Based Development** *** - [Introduction](https://trunkbaseddevelopment.com/ "Introduction") - [Context](https://trunkbaseddevelopment.com/context/ "Context") - [Five-minute overview](https://trunkbaseddevelopment.com/5-min-overview/ "Five-minute overview") - [Deciding factors](https://trunkbaseddevelopment.com/deciding-factors/ "Deciding factors") - [Version control system features](https://trunkbaseddevelopment.com/vcs-features/ "Version control system features") - [Version control system choices](https://trunkbaseddevelopment.com/vcs-choices/ "Version control system choices") - [Feature flags](https://trunkbaseddevelopment.com/feature-flags/ "Feature flags") - [Branch by Abstraction](https://trunkbaseddevelopment.com/branch-by-abstraction/ "Branch by Abstraction") - [Branch for release](https://trunkbaseddevelopment.com/branch-for-release/ "Branch for release") - [Release from trunk](https://trunkbaseddevelopment.com/release-from-trunk/ "Release from trunk") - [Styles and Trade-offs](https://trunkbaseddevelopment.com/styles/ "Styles and Trade-offs") - [Continuous Integration (CI)](https://trunkbaseddevelopment.com/continuous-integration/ "Continuous Integration (CI)") - [Committing straight to the trunk](https://trunkbaseddevelopment.com/committing-straight-to-the-trunk/ "Committing straight to the trunk") - [Short-Lived Feature Branches](https://trunkbaseddevelopment.com/short-lived-feature-branches/ "Short-Lived Feature Branches") - [Continuous Code Review](https://trunkbaseddevelopment.com/continuous-review/ "Continuous Code Review") - [Continuous Delivery (CD)](https://trunkbaseddevelopment.com/continuous-delivery/ "Continuous Delivery (CD)") - [Concurrent development of consecutive releases](https://trunkbaseddevelopment.com/concurrent-development-of-consecutive-releases/ "Concurrent development of consecutive releases") - [Application strangulation](https://trunkbaseddevelopment.com/strangulation/ "Application strangulation") - [Observed habits](https://trunkbaseddevelopment.com/observed-habits/ "Observed habits") - [You're doing it wrong](https://trunkbaseddevelopment.com/youre-doing-it-wrong/ "You're doing it wrong") - [Alternative branching models](https://trunkbaseddevelopment.com/alternative-branching-models/ "Alternative branching models") - [Monorepos](https://trunkbaseddevelopment.com/monorepos/ "Monorepos") - [Expanding Contracting Monorepos](https://trunkbaseddevelopment.com/expanding-contracting-monorepos/ "Expanding Contracting Monorepos") - [Game Changers](https://trunkbaseddevelopment.com/game-changers/ "Game Changers") - [Publications](https://trunkbaseddevelopment.com/publications/ "Publications") - [Book on this topic](https://trunkbaseddevelopment.com/book/ "Book on this topic") - [Key to branch diagrams](https://trunkbaseddevelopment.com/key/ "Key to branch diagrams") - [Contributions](https://trunkbaseddevelopment.com/contributions/ "Contributions") *** - [Site Source on GitHub](https://github.com/paul-hammant/tbd "See GitHub Repo") - [SHA-1 Published: 48428c89151d53206185b234e56b824b0889671c](https://github.com/paul-hammant/tbd/commit/48428c89151d53206185b234e56b824b0889671c) # Introduction ## One line summary 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. \* *main* for the Git community since 2020 (`master` with unsavory connotations before) ## Shared branches off mainline/main/trunk are bad at any release cadence:  ## Trunk-Based Development For Smaller Teams:  ## Scaled Trunk-Based Development:  ## Elaboration, Claims and Caveats  Trunk-Based Development is a key enabler of [Continuous Integration](https://trunkbaseddevelopment.com/continuous-integration/) and by extension [Continuous Delivery](https://trunkbaseddevelopment.com/continuous-delivery/). When individuals on a team are committing their changes to the trunk multiple times a day it becomes easy to satisfy the core requirement of Continuous Integration that all team members commit to trunk at least once every 24 hours. This ensures the codebase is always releasable on demand and helps to make Continuous Delivery a reality. The dividing line between small team Trunk-Based Development and scaled Trunk-Based Development is a subject to team size and commit rate consideration. The precise moment a dev team is no longer “small” and has transitioned to “scaled” is subject to practitioner debate. Regardless, teams perform a full “pre integrate” build (compile, unit tests, integration tests) on their dev workstations before committing/pushing for others (or bots) to see. ### Claims - You should do Trunk-Based Development instead of GitFlow and other branching models that feature multiple long-running branches - You can either do a direct to trunk commit/push (v small teams) or a Pull-Request workflow as long as those feature branches are short-lived and the product of a single dev-workstation , whether done solo, pair-programmed, or mob. If the mob is bigger and the change more all-encompassing, techniques should include feature flags, branch by abstraction and “don’t break the build” Of course, “Dev workstation” requires some interpretation in recent years. Development may be in a VM, or a dev container of sorts. Those could be local or in a cloud somewhere. ### Caveats - Depending on the team size, and the rate of commits, [short-lived feature branches](https://trunkbaseddevelopment.com/short-lived-feature-branches/) are used for code-review and build checking (CI), but not artifact creation or publication, to happen before commits land in the trunk for other developers to depend on. Such branches allow developers to engage in [eager and continuous code review](https://trunkbaseddevelopment.com/continuous-review/) of contributions before their code is integrated into the trunk. Very small teams may [commit direct to the trunk](https://trunkbaseddevelopment.com/committing-straight-to-the-trunk/). - Depending on the intended release cadence, there may be [release branches](https://trunkbaseddevelopment.com/branch-for-release/) that are cut from the trunk on a just-in-time basis, are ‘hardened’ before a release (without that being a team activity), and **those branches are deleted** some time after release. Alternatively, there may also be no release branches if the team is [releasing from Trunk](https://trunkbaseddevelopment.com/release-from-trunk/), and choosing a “fix forward” strategy for bug fixes. Releasing from trunk is also for high-throughput teams, too. - Teams should become adept with the related [branch by abstraction](https://trunkbaseddevelopment.com/branch-by-abstraction/) technique for longer to achieve changes, and use [feature flags](https://trunkbaseddevelopment.com/feature-flags/) in day to day development to allow for hedging on the order of releases (and other good things - see [concurrent development of consecutive releases](https://trunkbaseddevelopment.com/concurrent-development-of-consecutive-releases/)) - If you have more than a couple of developers on the project, you are going to need to hook up a [build server](https://trunkbaseddevelopment.com/continuous-integration/) to verify that their commits have **not broken the build** after they land in the trunk, and also when they are ready to be merged back into the trunk from a short-lived feature branch. - Development teams can casually flex up or down in size (in the trunk) without affecting throughput or quality. Proof? [Google does Trunk-Based Development](https://trunkbaseddevelopment.com/game-changers/#google-revealing-their-monorepo-trunk-2016) and have **35000 developers and QA automators** in that single [monorepo](https://trunkbaseddevelopment.com/monorepos/) trunk, that in their case can [expand or contract](https://trunkbaseddevelopment.com/expanding-contracting-monorepos/) to suit the developer in question. - People who practice the [GitHub-flow branching model](https://trunkbaseddevelopment.com/alternative-branching-models/#modern-claimed-high-throughput-branching-models) will feel that this is quite similar, but there is one small difference around where to release from. - People who practice the Gitflow branching model will find this **very different**, as will many developers used to the popular ClearCase, Subversion, Perforce, StarTeam, VCS [branching models of the past](https://trunkbaseddevelopment.com/alternative-branching-models/#legacy-branching-models). - [Many publications](https://trunkbaseddevelopment.com/publications/) promote Trunk-Based Development as we describe it here. Those include the best-selling ‘Continuous Delivery’ and ‘DevOps Handbook’. This should not even be controversial anymore\! ## History Trunk-Based Development is not a new branching model. The word ‘trunk’ is referent to the concept of a growing tree, where the fattest and longest span is the trunk, not the branches that radiate from it and are of more limited length. It has been a lesser known branching model of choice since the mid-nineties and considered tactically since the eighties. The largest of development organizations, like Google (as mentioned) and Facebook practice it at scale. Over 30 years different [advances to source-control technologies and related tools/techniques](https://trunkbaseddevelopment.com/game-changers/) have made Trunk-Based Development more (and occasionally less) prevalent, but it has been a branching model that many have stuck with through the years. ## This site This site attempts to collect all the related facts, rationale and techniques for Trunk-Based Development together in one place, complete with twenty-five diagrams to help explain things. All without using TBD as an acronym even ~~once~~ twice. © 2017-2020: [Paul Hammant](https://phdo.paulhammant.com/), with contributions from [friends](https://trunkbaseddevelopment.com/contributions/). Site built with [Hugo](https://www.gohugo.io/) with [Material](http://github.com/digitalcraftsman/hugo-material-docs) theme, via [Netlify](https://netlify.com/). [Contribute to this page](https://github.com/paul-hammant/tbd/edit/master/content//_index.md) [Next Context](https://trunkbaseddevelopment.com/context/ "Context")

## Introduction ## One line summary 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. \* *main* for the Git community since 2020 (`master` with unsavory connotations before) ## Shared branches off mainline/main/trunk are bad at any release cadence:  ## Trunk-Based Development For Smaller Teams:   ## Elaboration, Claims and Caveats  Trunk-Based Development is a key enabler of [Continuous Integration](https://trunkbaseddevelopment.com/continuous-integration/) and by extension [Continuous Delivery](https://trunkbaseddevelopment.com/continuous-delivery/). When individuals on a team are committing their changes to the trunk multiple times a day it becomes easy to satisfy the core requirement of Continuous Integration that all team members commit to trunk at least once every 24 hours. This ensures the codebase is always releasable on demand and helps to make Continuous Delivery a reality. The dividing line between small team Trunk-Based Development and scaled Trunk-Based Development is a subject to team size and commit rate consideration. The precise moment a dev team is no longer “small” and has transitioned to “scaled” is subject to practitioner debate. Regardless, teams perform a full “pre integrate” build (compile, unit tests, integration tests) on their dev workstations before committing/pushing for others (or bots) to see. ### Claims - You should do Trunk-Based Development instead of GitFlow and other branching models that feature multiple long-running branches - You can either do a direct to trunk commit/push (v small teams) or a Pull-Request workflow as long as those feature branches are short-lived and the product of a single dev-workstation , whether done solo, pair-programmed, or mob. If the mob is bigger and the change more all-encompassing, techniques should include feature flags, branch by abstraction and “don’t break the build” Of course, “Dev workstation” requires some interpretation in recent years. Development may be in a VM, or a dev container of sorts. Those could be local or in a cloud somewhere. ### Caveats - Depending on the team size, and the rate of commits, [short-lived feature branches](https://trunkbaseddevelopment.com/short-lived-feature-branches/) are used for code-review and build checking (CI), but not artifact creation or publication, to happen before commits land in the trunk for other developers to depend on. Such branches allow developers to engage in [eager and continuous code review](https://trunkbaseddevelopment.com/continuous-review/) of contributions before their code is integrated into the trunk. Very small teams may [commit direct to the trunk](https://trunkbaseddevelopment.com/committing-straight-to-the-trunk/). - Depending on the intended release cadence, there may be [release branches](https://trunkbaseddevelopment.com/branch-for-release/) that are cut from the trunk on a just-in-time basis, are ‘hardened’ before a release (without that being a team activity), and **those branches are deleted** some time after release. Alternatively, there may also be no release branches if the team is [releasing from Trunk](https://trunkbaseddevelopment.com/release-from-trunk/), and choosing a “fix forward” strategy for bug fixes. Releasing from trunk is also for high-throughput teams, too. - Teams should become adept with the related [branch by abstraction](https://trunkbaseddevelopment.com/branch-by-abstraction/) technique for longer to achieve changes, and use [feature flags](https://trunkbaseddevelopment.com/feature-flags/) in day to day development to allow for hedging on the order of releases (and other good things - see [concurrent development of consecutive releases](https://trunkbaseddevelopment.com/concurrent-development-of-consecutive-releases/)) - If you have more than a couple of developers on the project, you are going to need to hook up a [build server](https://trunkbaseddevelopment.com/continuous-integration/) to verify that their commits have **not broken the build** after they land in the trunk, and also when they are ready to be merged back into the trunk from a short-lived feature branch. - Development teams can casually flex up or down in size (in the trunk) without affecting throughput or quality. Proof? [Google does Trunk-Based Development](https://trunkbaseddevelopment.com/game-changers/#google-revealing-their-monorepo-trunk-2016) and have **35000 developers and QA automators** in that single [monorepo](https://trunkbaseddevelopment.com/monorepos/) trunk, that in their case can [expand or contract](https://trunkbaseddevelopment.com/expanding-contracting-monorepos/) to suit the developer in question. - People who practice the [GitHub-flow branching model](https://trunkbaseddevelopment.com/alternative-branching-models/#modern-claimed-high-throughput-branching-models) will feel that this is quite similar, but there is one small difference around where to release from. - People who practice the Gitflow branching model will find this **very different**, as will many developers used to the popular ClearCase, Subversion, Perforce, StarTeam, VCS [branching models of the past](https://trunkbaseddevelopment.com/alternative-branching-models/#legacy-branching-models). - [Many publications](https://trunkbaseddevelopment.com/publications/) promote Trunk-Based Development as we describe it here. Those include the best-selling ‘Continuous Delivery’ and ‘DevOps Handbook’. This should not even be controversial anymore\! ## History Trunk-Based Development is not a new branching model. The word ‘trunk’ is referent to the concept of a growing tree, where the fattest and longest span is the trunk, not the branches that radiate from it and are of more limited length. It has been a lesser known branching model of choice since the mid-nineties and considered tactically since the eighties. The largest of development organizations, like Google (as mentioned) and Facebook practice it at scale. Over 30 years different [advances to source-control technologies and related tools/techniques](https://trunkbaseddevelopment.com/game-changers/) have made Trunk-Based Development more (and occasionally less) prevalent, but it has been a branching model that many have stuck with through the years. ## This site This site attempts to collect all the related facts, rationale and techniques for Trunk-Based Development together in one place, complete with twenty-five diagrams to help explain things. All without using TBD as an acronym even ~~once~~ twice.