Trunk-Based Development Overview

• Trunk-based development is a Git workflow that integrates code changes directly into a single main branch to support continuous integration and immediate availability.
• The approach leverages feature toggles to control incomplete features, reducing merge complexity while maintaining rapid delivery without long-lived branch isolation.
• Empirical studies show that while merge frequency remains similar, merge effort is significantly reduced, making trunk-based development ideal for small, experienced teams.

Searching arXiv for the papers on arXiv 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 (Lopes et al., 11 Jul 2025). 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 (Prutchi et al., 2020). 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 (Lopes et al., 11 Jul 2025).

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” (Lopes et al., 11 Jul 2025). 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 (Lopes et al., 11 Jul 2025).

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” (Prutchi et al., 2020). 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 (Prutchi et al., 2020).

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 (Lopes et al., 11 Jul 2025). 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” (Prutchi et al., 2020). 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 (Prutchi et al., 2020). 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” (Prutchi et al., 2020). 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 (Prutchi et al., 2020). 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” (Prutchi et al., 2020).

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 (Prutchi et al., 2020). 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 (Lopes et al., 11 Jul 2025). 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 (Lopes et al., 11 Jul 2025). 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 (Lopes et al., 11 Jul 2025). 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 (Lopes et al., 11 Jul 2025). 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” (Lopes et al., 11 Jul 2025). 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 (Prutchi et al., 2020). 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” (Prutchi et al., 2020).

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 (Prutchi et al., 2020). 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$ (Prutchi et al., 2020). 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” (Prutchi et al., 2020).

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 $$\text{normalized number of merges} = (\#\text{merges} \times 100)/\#\text{commits},$$0 to $$\text{normalized number of merges} = (\#\text{merges} \times 100)/\#\text{commits},$$1 (Prutchi et al., 2020). The Wilcoxon paired test yields $$\text{normalized number of merges} = (\#\text{merges} \times 100)/\#\text{commits},$$2, with Cliff’s Delta $$\text{normalized number of merges} = (\#\text{merges} \times 100)/\#\text{commits},$$3, classified as a small effect size (Prutchi et al., 2020). The control corpus does not show a significant difference in effort per merge, with Wilcoxon paired $$\text{normalized number of merges} = (\#\text{merges} \times 100)/\#\text{commits},$$4 (Prutchi et al., 2020).

The same pattern appears in normalized merge effort,

$$\text{normalized number of merges} = (\#\text{merges} \times 100)/\#\text{commits},$$5

The mean declines from $$\text{normalized number of merges} = (\#\text{merges} \times 100)/\#\text{commits},$$6 actions before feature-toggle adoption to $$\text{normalized number of merges} = (\#\text{merges} \times 100)/\#\text{commits},$$7 after, and the median declines from $$\text{normalized number of merges} = (\#\text{merges} \times 100)/\#\text{commits},$$8 to $$\text{normalized number of merges} = (\#\text{merges} \times 100)/\#\text{commits},$$9, with Wilcoxon paired $C_{RQ2}$0 and Cliff’s Delta $C_{RQ2}$1, again a small effect size (Prutchi et al., 2020). The control corpus shows no significant difference, with Wilcoxon $C_{RQ2}$2 (Prutchi et al., 2020).

These results support a narrow but important proposition: trunk-based development, as enabled by feature toggles, correlates with easier merges rather than fewer merges (Prutchi et al., 2020). 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 (Prutchi et al., 2020). 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 (Prutchi et al., 2020). 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 (Prutchi et al., 2020). To account for differences in project activity and size, the study uses normalized metrics that incorporate number of commits and $C_{RQ2}$3.

For normalized number of defects,

$C_{RQ2}$4

the mean increases from $C_{RQ2}$5 before adoption to $C_{RQ2}$6 after, and the median increases from $C_{RQ2}$7 to $C_{RQ2}$8, but the Wilcoxon paired test yields $C_{RQ2}$9, so the increase is not statistically significant (Prutchi et al., 2020). 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 $9.40$0 (Prutchi et al., 2020).

For time per defect, defined as

$9.40$1

the mean rises from $9.40$2 days to $9.40$3 days and the median from $9.40$4 days to $9.40$5 days, but the difference is again not statistically significant, with Wilcoxon $9.40$6 and Cliff’s Delta $9.40$7, a small effect (Prutchi et al., 2020). The control corpus, however, shows a much larger and statistically significant increase from $9.40$8 to $9.40$9 days mean time per defect, with Wilcoxon $100$0 and Cliff’s Delta $100$1, a large effect (Prutchi et al., 2020).

For normalized time fixing defects,

$100$2

the mean increases from $100$3 to $100$4 and the median from $100$5 to $100$6, with Wilcoxon $100$7 and Cliff’s Delta $100$8, described in the study as a medium effect size (Prutchi et al., 2020). The control corpus again shows a significant increase, from $100$9 to $8.10$0 mean normalized time fixing defects, with Wilcoxon $8.10$1 and Cliff’s Delta $8.10$2, also a medium effect (Prutchi et al., 2020).

The authors are explicit that these findings do not establish that feature toggles caused the increase in defects or time-to-fix (Prutchi et al., 2020). 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 (Prutchi et al., 2020).

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 $8.10$3 developers and a survey with $8.10$4 analyzed responses (Lopes et al., 11 Jul 2025). In this sample, branch-based workflows dominate: $8.10$5 survey responses, or about $8.10$6, are branch-based, while $8.10$7, or about $8.10$8, are trunk-based, with $8.10$9 responses classified as stacked diffs (Lopes et al., 11 Jul 2025). 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 $p\mbox{-}value = 0.3292$0 to $p\mbox{-}value = 0.3292$1 members, while branch-based teams range from $p\mbox{-}value = 0.3292$2 to $p\mbox{-}value = 0.3292$3 members in the main sample, with even higher outliers (Lopes et al., 11 Jul 2025). A Mann-Whitney $p\mbox{-}value = 0.3292$4 test indicates a significant difference in team size between trunk-based and branch-based users, although the study emphasizes low statistical power, about $p\mbox{-}value = 0.3292$5, due to the small trunk-based sample and therefore refuses strong statistical conclusions (Lopes et al., 11 Jul 2025). Years of experience do not differ significantly, although trunk-based users are described as slightly more experienced on average (Lopes et al., 11 Jul 2025).

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 $p\mbox{-}value = 0.3292$6 mentions, as well as “Management,” “Failures,” and “Backend and Server” (Lopes et al., 11 Jul 2025). Interview coding adds “Code Management Complexity” with $p\mbox{-}value = 0.3292$7 mentions, “Testing and Rapid Deployment to Production” with $p\mbox{-}value = 0.3292$8, “Fast Incident Response Time” with $p\mbox{-}value = 0.3292$9, and “Focus on Delivery Speed” with $$\text{effort per merge} = \text{merge effort sum} / \#\text{merges},$$0 (Lopes et al., 11 Jul 2025). 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” (Lopes et al., 11 Jul 2025).

Conversely, factors discouraging trunk-based development include “Team and Project Size” with $$\text{effort per merge} = \text{merge effort sum} / \#\text{merges},$$1 mentions, “Maintenance” with $$\text{effort per merge} = \text{merge effort sum} / \#\text{merges},$$2, “Management” with $$\text{effort per merge} = \text{merge effort sum} / \#\text{merges},$$3, “CI/CD” with $$\text{effort per merge} = \text{merge effort sum} / \#\text{merges},$$4, and “Security” with $$\text{effort per merge} = \text{merge effort sum} / \#\text{merges},$$5 (Lopes et al., 11 Jul 2025). 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” (Lopes et al., 11 Jul 2025). 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 (Lopes et al., 11 Jul 2025).

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” (Lopes et al., 11 Jul 2025). This does not imply a universal rule; the authors caution that the sample is imbalanced and entirely Brazilian, and therefore not globally generalizable (Lopes et al., 11 Jul 2025). 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 (Prutchi et al., 2020). 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 (Prutchi et al., 2020). 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 (Lopes et al., 11 Jul 2025). 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 (Lopes et al., 11 Jul 2025). 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 (Lopes et al., 11 Jul 2025).

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 $$\text{effort per merge} = \text{merge effort sum} / \#\text{merges},$$6, precision $$\text{effort per merge} = \text{merge effort sum} / \#\text{merges},$$7, and recall $$\text{effort per merge} = \text{merge effort sum} / \#\text{merges},$$8; and the corpus consists of public GitHub projects rather than the internal repositories of companies such as Google or Facebook (Prutchi et al., 2020). 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 (Lopes et al., 11 Jul 2025).

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 (Lopes et al., 11 Jul 2025, Prutchi et al., 2020). 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 (Prutchi et al., 2020). 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 (Lopes et al., 11 Jul 2025).