---
title: Trunk-Based Development Overview
url: https://www.emergentmind.com/topics/trunk-based-development
type: topic
---

# Trunk-Based Development Overview

Searching arXiv for the provided papers and closely related work on trunk-based development and feature toggles.
Trunk-based development is a collaborative software development workflow in which developers integrate changes into a single main branch, the trunk, typically multiple times a day and with little or no use of long-lived branches. In the comparative terminology used in recent empirical work, trunk-based workflows are distinguished from branch-based workflows by their reliance on one shared remote branch rather than multiple remote branches with well-defined roles such as feature, integration, release, or hotfix branches [2507.08943]. In research on feature toggles, trunk-based development is also described as a mode in which “new features are implemented directly in the mainline of development” without the need for creating branches, with incomplete or risky functionality controlled through toggles rather than branch isolation [2007.05760]. Across the cited studies, trunk-based development is therefore not merely a branching convention but a coordination regime closely associated with continuous integration, rapid deployment, and reduced dependence on long-running branch divergence [2507.08943].

## 1. Definition and conceptual boundaries

Trunk-based development is defined in one study as a Git workflow where there is “a single remote main branch” and developers “commit directly to this trunk,” often “multiple times a day,” “without extensive branch creation,” so that “the codebase is always available on demand” [2507.08943]. The same source states that short-lived branches may still exist, but only as a convenience around frequent integration rather than as the structural backbone of the workflow. This places trunk-based development at one end of a spectrum whose other end consists of branch-based workflows built around multiple remote branches and staged migration of code from isolated branches toward the main branch as changes mature [2507.08943].

A second study frames trunk-based development through the lens of branch isolation. It states that branching “allows temporary code isolation” but may demand additional effort to merge parallel work back into the mainline, and that “the isolation caused by branches may impose challenges on the upcoming merging process” [2007.05760]. Within that framing, trunk-based development is the alternative in which “new features are implemented directly in the mainline of development” rather than in long-lived feature branches, with the expectation that complicated branch merges can be reduced [2007.05760].

The conceptual boundary between trunk-based and branch-based workflows is therefore structural rather than tool-specific. In one classification rule, if multiple remote branches are used as shared collaboration sites, the workflow is categorized as branch-based; otherwise, with a single shared remote branch, it is categorized as trunk-based [2507.08943]. This suggests that trunk-based development should be understood primarily as a workflow topology centered on immediate integration.

## 2. Relationship to feature toggles and dark launching

In the feature-toggle literature, trunk-based development is closely linked to feature toggles, also called feature flags, switches, or flippers. Feature toggles are defined as “surrounding features (functionalities) in the code with if statements to gain more control over their release process,” so that developers can decide “when and for whom the feature should be available” [2007.05760]. The essential mechanism is that deployment and availability are decoupled: code may be deployed while the corresponding functionality remains disabled.

The cited study connects this mechanism directly to trunk-based development through “Dark Launching,” defined as releasing disabled partial features directly in the production environment [2007.05760]. Because the feature remains disabled, developers may “change code directly in the main development line (i.e., trunk-based development) of the project instead of creating feature branches for isolating parallel changes” [2007.05760]. The same source gives a concrete workflow: a team can add a new feature directly to the mainline, keep it disabled while under development, release it into production without exposing it to users, and later enable or remove the toggle when the feature is ready.

This connection is central to contemporary descriptions of trunk-based development. In the cited evidence, feature toggles are not an incidental supplement but one of the principal mechanisms by which teams preserve continuous integration while avoiding long-lived branch isolation [2007.05760]. The literature reviewed in that study includes reports that companies adopted trunk-based development “with the adoption of a feature toggles framework” to avoid long-running branch merge effort, and that feature toggles were suggested “for continuous integration instead of feature branches” [2007.05760].

The same study adopts Fowler and Hodgson’s distinction between release or development toggles and business or long-term toggles. Release toggles are temporary and used to guard in-progress features; business toggles are longer-lived configuration switches, sometimes exposed to users [2007.05760]. Release toggles are the category most directly associated with trunk-based development because they substitute for long-lived feature branches during implementation and rollout.

## 3. Position within Git workflow taxonomies

Recent empirical work organizes collaborative Git workflows into two main families: branch-based workflows and trunk-based workflows [2507.08943]. Branch-based workflows “define a set of remote branches with well-defined objectives,” including feature branches, integration branches, main branches, release branches, and hotfix branches, with GitFlow identified as the canonical example [2507.08943]. By contrast, trunk-based workflows use one shared branch and minimal branching.

This distinction is not merely nomenclatural. In branch-based models, changes progress through explicit staging layers as they are verified and validated, whereas in trunk-based development integration occurs at the earliest possible point into the shared mainline [2507.08943]. The comparative analysis reports that many practitioners do not explicitly name their workflow as GitFlow or trunk-based, but their step-by-step descriptions still reveal the underlying topology [2507.08943]. The prevalence of customized branch models also indicates that trunk-based development frequently appears in practice as a family of closely related patterns rather than as a rigid textbook prescription.

One study reports that at least one team uses both models: trunk-based for “small/simple maintenance tasks” and a GitFlow-like branch-based workflow for “larger/complex work” [2507.08943]. This suggests heterogeneous and hybrid practice. A plausible implication is that trunk-based development should be treated not only as a pure workflow type but also as a strategy that can coexist with branch-based mechanisms for particular task classes.

## 4. Empirical evidence on merges and integration cost

The strongest quantitative evidence in the supplied material concerns the correlation between feature toggle adoption and merge behavior in 949 open-source GitHub projects written in C#, Java, JavaScript, PHP, Python, and Ruby [2007.05760]. The study identifies the first commit in which a known feature toggle framework appears and partitions each project history into periods before and after adoption. It then analyzes branch merges using a heuristic that treats a merge commit as a branch merge if more than one unique developer contributed to each side of the merge, and also scans merge commit messages for “merge branch” [2007.05760].

To quantify merge complexity, the study adopts the Prudêncio et al. metric as implemented by Moura and Murta. Actions are modeled as a multiset of added and removed lines, and merge effort is defined as the total number of actions in the multiset that remain after subtracting the combined branch actions from the merge actions [2007.05760]. In the study’s formulation, a purely automatic merge has effort \(0\), while higher values reflect more manual conflict-resolution work.

For normalized number of merges, defined as
\[
\text{normalized number of merges} = (\#\text{merges} \times 100)/\#\text{commits},
\]
the study finds no statistically significant reduction after adoption of feature toggles. In the merge corpus \(C_{RQ2}\) of 158 projects, the median changes from \(9.40\) merges per \(100\) commits before feature toggles to \(8.10\) after, with Wilcoxon paired \(p\mbox{-}value = 0.3292\) [2007.05760]. The authors conclude that they “could not observe a significant reduction in the number of merges” and “cannot say that the use of feature toggles frameworks has any impact on the number of merges” [2007.05760].

By contrast, effort per merge decreases markedly. With
\[
\text{effort per merge} = \text{merge effort sum} / \#\text{merges},
\]
the mean falls from \(13.34\) before adoption to \(1.68\) after, while the median falls from \(0.56\) to \(0.04\) [2007.05760]. The Wilcoxon paired test yields \(p\mbox{-}value = 0.039\), with Cliff’s Delta \(d = 0.1889\), classified as a small effect size [2007.05760]. The control corpus does not show a significant difference in effort per merge, with Wilcoxon paired \(p\mbox{-}value = 0.683\) [2007.05760].

The same pattern appears in normalized merge effort,
\[
\text{normalized merge effort} = \text{normalized number of merges} \times \text{effort per merge}.
\]
The mean declines from \(87.58\) actions before feature-toggle adoption to \(17.97\) after, and the median declines from \(3.86\) to \(0.40\), with Wilcoxon paired \(p\mbox{-}value = 0.002\) and Cliff’s Delta \(d = 0.205\), again a small effect size [2007.05760]. The control corpus shows no significant difference, with Wilcoxon \(p\mbox{-}value = 0.480\) [2007.05760].

These results support a narrow but important proposition: trunk-based development, as enabled by feature toggles, correlates with easier merges rather than fewer merges [2007.05760]. The study explicitly notes that “some projects, in fact, completely migrated to trunk-based development after the adoption of feature toggles,” but that branch usage persisted across the corpus [2007.05760]. This suggests heterogeneity in how fully projects operationalize the trunk-based model.

## 5. Defects, time-to-fix, and quality-related findings

The same open-source study examines defects and defect-fixing time relative to feature-toggle adoption [2007.05760]. Defects are approximated from GitHub issues and pull requests through labels and textual heuristics, and time-to-fix is measured as the number of days between issue creation and closure [2007.05760]. To account for differences in project activity and size, the study uses normalized metrics that incorporate number of commits and \(KLOC\).

For normalized number of defects,
\[
\text{normalized number of defects} = (\#\text{defects} \times 100)/\#\text{commits}/(KLOC/\#\text{commits}),
\]
the mean increases from \(0.48\) before adoption to \(2.67\) after, and the median increases from \(0.03\) to \(0.16\), but the Wilcoxon paired test yields \(p\mbox{-}value = 0.1184\), so the increase is not statistically significant [2007.05760]. The authors state that they “could not observe a statistically significant difference in the normalized number of defects after adopting feature toggles,” while also noting that mean and median increased by more than \(400\%\) [2007.05760].

For time per defect, defined as
\[
\text{time per defect} = \text{defects time sum}/\#\text{defects},
\]
the mean rises from \(14.66\) days to \(20.79\) days and the median from \(1.56\) days to \(4.89\) days, but the difference is again not statistically significant, with Wilcoxon \(p\mbox{-}value = 0.097\) and Cliff’s Delta \(d = -0.292\), a small effect [2007.05760]. The control corpus, however, shows a much larger and statistically significant increase from \(32.66\) to \(178.51\) days mean time per defect, with Wilcoxon \(p\mbox{-}value = 7.663 \times 10^{-10}\) and Cliff’s Delta \(d = -0.570\), a large effect [2007.05760].

For normalized time fixing defects,
\[
\text{normalized time fixing defects} = (\text{defects time sum} \times 100)/\#\text{commits}/(KLOC/\#\text{commits}),
\]
the mean increases from \(6.96\) to \(25.91\) and the median from \(0.16\) to \(0.77\), with Wilcoxon \(p\mbox{-}value = 0.1661\) and Cliff’s Delta \(d = 0.2361\), described in the study as a medium effect size [2007.05760]. The control corpus again shows a significant increase, from \(189.57\) to \(3{,}415.45\) mean normalized time fixing defects, with Wilcoxon \(p\mbox{-}value = 1.636 \times 10^{-06}\) and Cliff’s Delta \(d = -0.351\), also a medium effect [2007.05760].

The authors are explicit that these findings do not establish that feature toggles caused the increase in defects or time-to-fix [2007.05760]. In relation to trunk-based development, the evidence therefore remains mixed. The data support easier integration, but they do not support strong claims of improved quality or faster defect resolution attributable to feature-toggle-enabled trunk-based workflows. The same study notes Fowler’s warning that feature toggles create testing challenges because of the number of possible toggle combinations [2007.05760].

## 6. Organizational contexts and comparative suitability

A 2025 mixed-methods study of Brazilian developers compares trunk-based and branch-based workflows through semi-structured interviews with \(22\) developers and a survey with \(50\) analyzed responses [2507.08943]. In this sample, branch-based workflows dominate: \(42/50\) survey responses, or about \(84\%\), are branch-based, while \(6/50\), or about \(12\%\), are trunk-based, with \(2\) responses classified as stacked diffs [2507.08943]. The study therefore presents trunk-based development as a minority workflow in the sampled population.

The same study associates trunk-based development with smaller teams. Trunk-based teams range from \(1\) to \(5\) members, while branch-based teams range from \(1\) to \(20\) members in the main sample, with even higher outliers [2507.08943]. A Mann-Whitney \(U\) test indicates a significant difference in team size between trunk-based and branch-based users, although the study emphasizes low statistical power, about \(32.9\%\), due to the small trunk-based sample and therefore refuses strong statistical conclusions [2507.08943]. Years of experience do not differ significantly, although trunk-based users are described as slightly more experienced on average [2507.08943].

Qualitative coding identifies several factors favoring trunk-based development. Survey respondents cite “Easiness and Practicality,” “Agility,” “Quick Versioning,” and “Team and Project Size,” each with \(5\) mentions, as well as “Management,” “Failures,” and “Backend and Server” [2507.08943]. Interview coding adds “Code Management Complexity” with \(12\) mentions, “Testing and Rapid Deployment to Production” with \(11\), “Fast Incident Response Time” with \(4\), and “Focus on Delivery Speed” with \(4\) [2507.08943]. Illustrative quotations describe lower complexity, fewer processes in deployment because “it is just one pipeline,” and the ability to get a fix into production in “less than half a day” [2507.08943].

Conversely, factors discouraging trunk-based development include “Team and Project Size” with \(7\) mentions, “Maintenance” with \(5\), “Management” with \(2\), “CI/CD” with \(2\), and “Security” with \(2\) [2507.08943]. Respondents mention simultaneous commits by many developers, interference between commits and pushes, difficulty with feature toggles, slow pipelines, low experience in continuous delivery, and concern that the model “lacks testing security” [2507.08943]. Interview findings reinforce the perception that trunk-based development is risky for teams “composed mostly of less experienced developers,” while branch-based workflows are seen as safer in settings with separate environments, rigid processes, and strong quality-control requirements [2507.08943].

The study’s main comparative conclusion is that trunk-based development “favors fast-paced projects with experienced and smaller teams,” while branch-based development “suits less experienced and larger teams better, despite posing management challenges” [2507.08943]. This does not imply a universal rule; the authors caution that the sample is imbalanced and entirely Brazilian, and therefore not globally generalizable [2507.08943]. Still, within the supplied evidence, the organizational niche of trunk-based development is characterized by small team size, delivery speed, and operational maturity in CI/CD and monitoring.

## 7. Limitations, misconceptions, and interpretive cautions

The supplied evidence identifies several recurrent misconceptions about trunk-based development. One is that trunk-based development necessarily eliminates merges. The open-source study does not support that claim: even though feature toggles “enable trunk-based development,” the normalized number of merges does not change significantly after adoption [2007.05760]. The evidence therefore supports a more precise statement: trunk-based development may reduce merge effort even when merges continue to occur.

A second misconception is that trunk-based development is equivalent to direct commits without any auxiliary mechanisms. The feature-toggle study presents feature toggles as a central operational mechanism that allows incomplete work to be integrated into trunk while remaining disabled [2007.05760]. The comparative workflow study similarly notes that trunk-based development aligns with CI/CD and, in the practical guidance derived from the study, that safe adoption requires good automated testing, monitoring, and feature management [2507.08943]. This suggests that trunk-based development is best understood as a socio-technical configuration rather than a bare rule against branch creation.

A third misconception is that trunk-based development is inherently superior across all contexts. The evidence provided does not justify such a generalization. Branch-based workflows dominate the survey sample and are favored in larger teams, in settings with separate environments, and in regulated or high-risk domains such as financial services [2507.08943]. The trunk-based model is reported as advantageous where speed, simplicity, and rapid incident response matter, but as difficult to manage when teams are large, pipelines are slow, or contributors are less experienced [2507.08943].

Several methodological limitations also constrain interpretation. The open-source study detects feature toggles only through known frameworks and therefore excludes projects that implement toggles manually; it does not account for rebase workflows; its branch-merge classifier is heuristic; defect detection from issues has reported accuracy around \(77\%\), precision \(68\%\), and recall \(53\%\); and the corpus consists of public GitHub projects rather than the internal repositories of companies such as Google or Facebook [2007.05760]. The comparative workflow study is limited by voluntary participation, a sample consisting only of Brazilian developers, subjective workflow classification from free-text responses, and a very small trunk-based subgroup [2507.08943].

Taken together, the studies support a restrained synthesis. Trunk-based development is a workflow centered on immediate integration into a single main branch, usually supported by CI/CD and often by feature toggles [2507.08943][2007.05760]. Empirical evidence indicates that such practices correlate with lower merge effort and lower normalized merge effort, but not with a statistically significant reduction in merge frequency [2007.05760]. The evidence on defects and repair time is inconclusive, and organizational suitability appears contingent on team size, experience, delivery cadence, and process requirements rather than on a universal superiority of one workflow over another [2507.08943].

Source: https://www.emergentmind.com/topics/trunk-based-development