# Trunk-based development

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/trunk-based-development

## Quick definition

Trunk-based development is a way of working with code where everyone on a team regularly saves their small changes to a single shared version of the project, called the 'trunk.' Instead of creating separate long-lived branches, developers commit their updates several times a day, which helps catch conflicts early and keeps the software always ready to release. This practice is favored by teams that want to deliver updates quickly and reliably.

## Simple meaning

Trunk-based development is like a busy highway with many cars merging in, rather than every car taking its own separate side road. Imagine a main road where all drivers agree to merge frequently and carefully, so traffic flows smoothly and accidents are caught early. In software terms, the 'trunk' is the main line of code that everyone works from. Instead of creating a long-lasting separate branch to develop a new feature in isolation, developers make small, safe changes several times a day directly to that main trunk. This constant merging means that any problems, like two developers editing the same file in conflicting ways, are discovered within minutes rather than weeks. The team can immediately fix the conflict, keeping the codebase stable. Because everyone is always working from the latest version, the software is always in a state that could potentially be released. This is different from other methods where features are built in isolation over days or weeks, leading to painful integrations. Trunk-based development reduces the risk of big messy merges and makes automated testing and continuous delivery much easier. It also encourages smaller, more manageable changes since each commit is small. The team relies heavily on good automated tests to catch issues before they reach production. For IT certification learners, understanding this practice is key because it shows how modern DevOps teams achieve speed without sacrificing quality. It is a practical way of working that directly supports the goals of continuous integration and continuous delivery.

## Technical definition

Trunk-based development is a source control branching model where all developers share a single branch, typically called 'main' or 'trunk,' and commit their changes directly to it at least once per day, often many times per day. The core principle is to avoid long-lived feature branches. Instead, features are broken down into small, incremental changes that can be completed and integrated within hours. This practice relies on a robust suite of automated testing and continuous integration (CI) pipelines to validate each commit. If a commit breaks the build or introduces a regression, the team is expected to revert or fix it immediately, often through short-lived 'release branches' only created just before a production release. In implementations like Google or Netflix, developers may use feature toggles (also known as feature flags) to hide incomplete code, allowing them to commit partially finished work to the trunk without affecting users. This technique enables continuous integration and deployment because the trunk is always in a releasable state. In contrast to GitFlow or other models with multiple long-lived branches (develop, feature, release, hotfix), trunk-based development reduces the complexity of merge conflicts, the time spent on branch management, and the risk of integration hell. It is commonly associated with DevOps and CI/CD pipelines. The protocol for managing branches in trunk-based development typically involves only the trunk and short-lived topic branches (created for a few hours). Code reviews are often done on these short-lived branches before merging to the main trunk. In terms of standards, there are no formal protocols specific to trunk-based development, but it aligns closely with industry practices for continuous delivery, such as using feature flags, automated testing, and build automation. The real IT implementation often involves using version control tools like Git with strict branch protection rules that enforce CI checks before merge, and a culture of reverting faulty changes quickly rather than fixing forward on a broken trunk.

## Real-life example

Imagine a large restaurant kitchen where several chefs are preparing different dishes for a busy dinner service. In the old way of working, each chef would take their own separate worktable and prep all the ingredients for their dish in isolation. Hours later, they would bring everything together to combine into the final meal. Often, they would discover that one chef used the last of the garlic, or another chef cut the vegetables in the wrong shape, and the whole meal became a stressful mess. Trunk-based development is like a kitchen where all chefs work at the same large island, constantly sharing ingredients and tools. Each chef adds a small amount of their prepared item to the communal pot every few minutes, not waiting until the entire dish is done. They constantly taste and adjust, so if someone adds too much salt, it is noticed and fixed right away. The main work surface (the trunk) always has a balanced, almost-ready meal. Instead of a frantic final assembly, the meal is built continuously, and any conflicts are resolved immediately. This kitchen runs more smoothly, produces consistent quality, and can serve customers faster. It requires good communication and trust, just like trunk-based development requires good automated tests and a shared commitment to keep the main branch stable. This analogy shows how frequent integration avoids the chaos of large, late-stage merges and makes the entire process faster and more reliable, which is the core goal of trunk-based development.

## Why it matters

Trunk-based development matters because it directly enables the fast, reliable software delivery that modern IT organizations demand. In a world where companies release updates multiple times per day, the traditional approach of long-lived feature branches becomes a bottleneck. Developers spend hours or days merging and resolving conflicts, which delays feedback and increases risk. Trunk-based development removes this bottleneck by encouraging small, frequent commits that are integrated continuously. This practice reduces the dreaded 'merge hell' where two weeks of work by two developers conflicts massively. It also supports continuous integration by ensuring that the main branch is always in a potentially shippable state. For IT professionals, adopting trunk-based development means less time wrestling with version control and more time delivering value. It also improves team collaboration, as developers must communicate more frequently about their changes. From an exam perspective, understanding trunk-based development is essential for DevOps and CI/CD related certifications such as AWS DevOps Engineer, Azure DevOps, and the Google Cloud DevOps Engineer. Questions often focus on how to implement it in practice, the role of feature flags, and the importance of automated testing. It also appears in general IT certifications like the CompTIA Cloud+ or ITIL, where discussions of deployment frequency and release management are relevant. The practical IT context is that companies like Facebook, Netflix, and Google rely on trunk-based development to deploy hundreds of changes a day. Without it, their speed would be impossible. Therefore, this is not a niche practice but a core strategy for any serious DevOps implementation.

## Why it matters in exams

Trunk-based development is a key concept in DevOps-related certification exams. For example, in the AWS Certified DevOps Engineer – Professional exam, it falls under the domain of 'SDLC Automation' and 'Configuration Management and Infrastructure as Code.' You might see scenario questions where you need to choose a branching strategy that supports continuous delivery, and trunk-based development is often the correct answer. Similarly, in the Microsoft Azure DevOps Solutions (AZ-400) exam, trunk-based development is referenced in the context of implementing a branching strategy that facilitates continuous integration. The Google Cloud DevOps Engineer certification also covers this, as it aligns with the principles of continuous delivery and reducing cycle time. Even in general IT exams like the CompTIA Cloud+ or the ITIL Foundation, trunk-based development may appear as an example of modern development practice that supports fast release cycles. In exam questions, you are typically asked to identify the best branching strategy for a team that wants to release frequently and reduce integration problems. Another common question type presents a scenario where a team using long-lived feature branches suffers from merge conflicts, and you must recommend trunk-based development as the solution. Some questions explore the trade-offs, such as the need for feature flags and robust automated testing. Understanding the difference between trunk-based development and GitFlow is a frequent point of confusion. The exam trap often involves a question where a team wants to avoid breaking the main branch, and a distractor suggests using long-lived feature branches. You must know that trunk-based development actually uses feature flags and short-lived branches, not long-lived ones, to maintain stability. Another trap is that trunk-based development does not mean committing directly to production without testing. It still requires CI pipelines and code reviews, just with very short-lived branches. Therefore, when studying for these exams, focus on the characteristics of trunk-based development: single main branch, short-lived branches, frequent commits, feature flags, and strong CI.

## How it appears in exam questions

In certification exams, trunk-based development appears in several distinct question patterns. The most common is the scenario-based question. For example: 'A development team is experiencing frequent merge conflicts and long integration cycles because they use long-lived feature branches. The team wants to adopt continuous deployment. Which branching strategy should they adopt?' The correct answer is trunk-based development. Another pattern is the configuration question: 'You are setting up a CI/CD pipeline for a team that practices trunk-based development. Which branch should trigger the build and deployment to production?' The answer is the main branch (trunk). Some questions test understanding of feature flags: 'In trunk-based development, how do you handle incomplete features that are not ready for release?' The answer is using feature toggles or feature flags. Questions may also present a troubleshooting scenario: 'After implementing trunk-based development, the team notices frequent broken builds. What is the most likely missing component?' The answer is insufficient automated testing or insufficient test coverage. Another question type asks about the difference between trunk-based development and other branching strategies: 'Which of the following is a characteristic of trunk-based development but not of GitFlow?' The answer could be 'single main branch' or 'no long-lived feature branches.' There are also questions about the appropriate length of a branch in trunk-based development, where the answer is a few hours or less, not days. Some exams ask about the relationship to continuous integration: 'Trunk-based development is a prerequisite for which continuous integration practice?' The answer is frequent integration and automated builds. Finally, there are questions about best practices: 'To safely adopt trunk-based development, what must a team implement?' The answer is a comprehensive suite of automated tests and a reliable CI pipeline. These question patterns emphasize the practical application of the strategy rather than memorizing definitions.

## Example scenario

You are a DevOps engineer at a small software company that develops a mobile app. Currently, the development team uses GitFlow with separate develop and feature branches. Each feature takes about one week to build, and at the end of the sprint, the team merges all feature branches into the develop branch and then into main for release. The last sprint was a disaster. Two developers worked on features that touched the same payment module. When they merged, there were dozens of conflicts, and it took two days to resolve them. The release was delayed, and a bug slipped into production because the merge was rushed. The team is frustrated. Your manager asks you to recommend a new branching strategy that will reduce merge conflicts and enable faster releases. You recommend trunk-based development. Here is how you would implement it: First, you set up a single main branch (trunk) and protect it with a rule that requires all commits to pass CI checks before merging. You create short-lived topic branches that last no more than a few hours. Developers commit their small changes to these topic branches, create a pull request, and once it passes code review and automated tests, they merge it into trunk. If a change is too large to finish in a few hours, the developer uses a feature flag to hide the incomplete code in trunk. The team also agrees to fix or revert any commit that breaks the build within 30 minutes. After two weeks, the team notices a dramatic reduction in merge conflicts. Releases happen daily instead of monthly. The team is happier and more productive. This scenario shows how trunk-based development transforms a struggling team into a high-performing delivery team.

## Common mistakes

- **Mistake:** Thinking trunk-based development means everyone commits directly to the main branch without any testing.
  - Why it is wrong: Trunk-based development still requires automated testing and often uses short-lived branches for code review. Committing directly without testing would break the build constantly.
  - Fix: Understand that trunk-based development uses short-lived branches (hours) and CI pipelines to validate every change before merging.
- **Mistake:** Believing that trunk-based development prohibits the use of any branches at all.
  - Why it is wrong: Trunk-based development does allow short-lived topic branches for a few hours. The key is that they are merged quickly into the trunk, not kept for days or weeks.
  - Fix: Think of trunk-based development as having branches that live for hours, not weeks, and are merged after passing CI and code review.
- **Mistake:** Confusing trunk-based development with using only a single branch and no feature flags.
  - Why it is wrong: Feature flags are a common complement to trunk-based development to hide incomplete work. Without them, you cannot commit partially finished features to the trunk safely.
  - Fix: Learn that trunk-based development often uses feature toggles to allow incomplete code in the trunk without affecting users.
- **Mistake:** Assuming that trunk-based development is only suitable for very small teams.
  - Why it is wrong: Large companies like Google and Facebook use trunk-based development with thousands of developers. It scales with good tooling and automated testing.
  - Fix: Recognize that trunk-based development scales when combined with feature flags, strong CI, and a culture of reverting broken commits.
- **Mistake:** Thinking that trunk-based development means releasing every commit immediately to production.
  - Why it is wrong: Trunk-based development keeps the trunk in a releasable state, but actual releases may be gated by release branches or feature flags. Not every commit goes to production instantly.
  - Fix: Understand that 'release-ready' does not mean 'released immediately.' Releases are still controlled by business decisions.

## Exam trap

{"trap":"A question asks: 'A team wants to adopt trunk-based development. What is the most important practice to implement?' The distractor options include 'long-lived feature branches' or 'code freezes before release.'","why_learners_choose_it":"Learners may think that long-lived feature branches help organize work, or that code freezes ensure stability, both of which are common in other strategies.","how_to_avoid_it":"Remember that trunk-based development explicitly avoids long-lived branches. The correct practice to implement is a strong automated testing suite and CI pipeline, along with feature flags. Code freezes are unnecessary because the trunk is always release-ready."}

## Commonly confused with

- **Trunk-based development vs GitFlow:** GitFlow uses multiple long-lived branches like develop, feature, release, and hotfix, which can last for days or weeks. Trunk-based development uses only a single main branch with very short-lived topic branches. GitFlow is more complex and less suitable for continuous delivery. (Example: In GitFlow, you might have a feature branch that lasts two weeks. In trunk-based development, that same feature would be broken into daily commits to the trunk, hidden behind a feature flag.)
- **Trunk-based development vs Feature branch development:** Feature branch development refers to the general practice of creating a separate branch for each feature, often for a long period. Trunk-based development is a specific type of feature branch development but with very short-lived branches and a focus on continuous integration. (Example: A team using feature branch development might keep a branch open for a month. A trunk-based development team merges their feature branch within a few hours.)
- **Trunk-based development vs Continuous integration:** Continuous integration is the practice of merging code changes frequently and automatically building and testing. Trunk-based development is a branching strategy that helps achieve continuous integration. You can do CI without trunk-based development, but trunk-based development makes CI easier. (Example: A team can do CI with GitFlow by merging often, but trunk-based development is specifically designed to support very high frequency integration.)

## Step-by-step breakdown

1. **Set up a single main branch as the trunk** — Create a branch named 'main' (or 'trunk') in your version control system. This is the only branch that will be used for integration and releases. All developers base their work on this branch.
2. **Create a short-lived topic branch from the trunk** — When a developer needs to make a change, they create a branch from the trunk. This branch should exist only for a few hours, enough time to make a small change and run tests. It is not for large, long-term feature work.
3. **Commit small changes frequently** — Developers make several small commits per day. Each commit should represent a single, logical change that is as small as possible. This makes it easier to review, test, and revert if necessary.
4. **Run automated tests via CI pipeline** — Every commit triggers a continuous integration pipeline that runs automated tests. If the tests pass, the commit is eligible for merge. If they fail, the developer must fix the issue immediately or revert the commit.
5. **Merge the topic branch into the trunk after code review** — The developer creates a pull request for the topic branch. Code review happens quickly. Once approved and CI passes, the branch is merged into the trunk. The topic branch is then deleted. The trunk now contains the new change.
6. **Use feature flags for incomplete work** — If a change is part of a larger feature that is not ready, the developer wraps the new code behind a feature flag. This allows the code to be merged into the trunk without affecting users. The feature flag can be toggled on later when the feature is complete.
7. **Release directly from the trunk (or a short-lived release branch)** — When it is time to release, the team takes the current state of the trunk and creates a release branch if needed. This release branch is short-lived and used only for final validation. After release, the trunk continues to receive new commits.

## Practical mini-lesson

Trunk-based development is not just a theoretical concept; it is a practical workflow that requires discipline and tooling. In practice, the most critical component is a robust continuous integration (CI) system. Every commit to the trunk must be validated by a suite of automated tests. These tests should include unit tests, integration tests, and, if possible, end-to-end tests. The CI pipeline must be fast, ideally completing in less than ten minutes, so that developers get quick feedback. If the build breaks, the team must prioritize fixing it above all else. A common practice is to have a 'broken build' protocol: if a commit breaks the trunk, the developer who broke it either fixes it within 15-30 minutes or reverts the commit. This keeps the trunk stable for everyone. Feature flags (or toggles) are essential for hiding incomplete work. They can be implemented with simple environment variables or dedicated feature flag management tools like LaunchDarkly. Developers should use feature flags for any change that is not ready to be exposed to users. This allows them to merge code to the trunk even if the feature is only 20% complete. Another practical consideration is commit size. Developers should aim for commits that are small enough that they can be reviewed and merged within a few hours. This means breaking down large features into many small increments. For example, instead of a two-week feature branch, the developer commits the database schema change on day one (hidden behind a flag), the backend API endpoint on day two, and the frontend UI on day three. Each of these commits is small and low risk. In professional settings, code reviews are still performed, but they are quick and focused. Reviewers are expected to prioritize reviews for trunk-based development teams to avoid blocking the flow. Finally, release management from the trunk involves creating a release branch only when a release is imminent. This branch is used for final stabilization and then deleted. After release, any necessary hotfixes are made directly on the main trunk and cherry-picked to the release branch if still needed. Common pitfalls include not having enough test coverage, leading to frequent broken builds, and not using feature flags properly, causing incomplete features to leak to users. Teams must also avoid the temptation to create long-lived branches again. Disciplined adherence to the principles is key. For IT professionals, mastering trunk-based development means understanding that it is not just about branching; it is about engineering culture, automation, and continuous delivery.

## Memory tip

Think of a tree: the trunk is the single main line. All branches are short and reattach quickly to the trunk. Frequent merging keeps the tree healthy.

## FAQ

**Can I use trunk-based development with Git?**

Yes, Git is the most common version control system for trunk-based development. You can set up branch protection rules and CI pipelines easily with Git.

**Is trunk-based development the same as continuous integration?**

No, it is a branching strategy that enables continuous integration. Continuous integration is the practice of merging code frequently, and trunk-based development is a way to achieve that.

**What size should commits be in trunk-based development?**

Commits should be as small as possible, ideally one logical change per commit. They should be small enough to be developed, tested, and merged within a few hours.

**Do I need feature flags to use trunk-based development?**

Not strictly, but they are highly recommended. Feature flags allow you to merge incomplete code to the trunk without affecting users, which is a common need in trunk-based development.

**How do I prevent the trunk from becoming unstable?**

Implement a strong CI pipeline with comprehensive tests. Enforce a policy that requires any broken commit to be fixed or reverted within a short time, usually 15-30 minutes.

**Can large teams use trunk-based development?**

Yes, companies like Google and Netflix use trunk-based development with thousands of developers. It requires good tooling, automated testing, and a strong engineering culture.

## Summary

Trunk-based development is a branching strategy that keeps the main branch as the single source of truth, with all developers committing small changes frequently. This approach minimizes merge conflicts, supports continuous integration, and enables fast, reliable releases. It is a foundational practice for modern DevOps and is heavily tested in certifications like AWS DevOps Engineer, Azure DevOps, and Google Cloud DevOps Engineer. By understanding the principles of trunk-based development, including the use of short-lived branches, strong CI pipelines, and feature flags, you can improve team efficiency and exam performance. The key takeaways are that trunk-based development is not about avoiding branches altogether, but about making them very short-lived; it requires robust automation and a culture of immediate fix or revert; and it is a scalable practice used by top tech companies. For your exam, remember that trunk-based development is the answer when the question asks for a branching strategy that supports continuous delivery and reduces integration pain.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/trunk-based-development