How to adopt a trunk-based development workflow

What and why

Trunk-based development means everyone integrates small changes into one main branch frequently, instead of maintaining long-lived feature branches that diverge and produce painful merges. Combined with feature flags, it lets you deploy continuously while releasing features when ready.

Prerequisites

• A Git repository with a main branch.
• A CI pipeline that runs on every change.
• Permission to configure branch protection.

Steps

1. Define the trunk

Designate main as the trunk. All work targets it; there are no parallel long-running release branches in the common case.

2. Protect the trunk

Require passing CI and at least one review before merge. Branch protection keeps the trunk releasable at all times, which is the core promise of the model.

3. Work in short-lived branches

Create a branch, make a small change, open a pull request, and merge within a day or two:

git switch -c add-search
# small change
git push -u origin add-search

Short branches minimize divergence and merge pain.

4. Hide unfinished work behind flags

Wrap incomplete features in a flag so they can merge to trunk without being visible:

if (flags.isEnabled('new-search')) {
  renderNewSearch();
}

This decouples deploying code from releasing a feature.

5. Keep CI fast and green

Frequent integration only works if CI is quick and reliable. Parallelize tests and fix flaky ones promptly so the trunk stays green.

Verification

Review merge frequency: most branches should merge within a couple of days. Confirm the trunk is always deployable by deploying from it on demand. Toggle a flag and watch a hidden feature appear without a new deploy.

Next Steps

Move toward continuous deployment once trunk stability is high. Add a flag-management system to control rollouts. Use release tags or cherry-picks only for genuine hotfix needs.