Trunk-based development: merging to main at least once a day, in plain words for PMs

Trunk-based development is a way of working where every developer merges small changes into one shared branch — the trunk, usually called main — at least once a day, and hides anything unfinished behind a feature flag. There are no feature branches that live for weeks; a branch lasts hours, sometimes a day. The point is to keep the whole team on the same code and to make every change small enough that it can be reviewed, tested and shipped almost immediately.

The one rule that matters

The whole model hangs on one rule: integrate into the trunk at least once every working day. "Trunk" is an old word for the main line of a tree, and in Git it simply means the main branch — the one called main (or master on older repositories). Everything else branches off it and merges back into it quickly.

The opposite is a "long-lived feature branch": a branch that lives for a week or more while someone builds a feature in private, then merges a huge pile of changes in one go. Trunk-based development exists to make that pile as small as possible. Instead of one big merge at the end of the week, you get many tiny merges every day.

What a working day looks like

A developer picks a small, self-contained slice of work, not a whole feature. They branch from main, commit two or three times, open a pull request within hours, and it gets reviewed and merged the same day. If the feature is only half done, the parts that exist still merge — hidden behind a feature flag, a switch that turns that part of the product on or off without a new deploy.

For a one-line fix, many trunk-based teams don't even branch: they commit straight to main, because a change that small is easy to review in place and easy to revert if it breaks something.

The rhythm to remember is: small branch, quick review, merge, deploy, repeat.

Why teams do it

1. Merge conflicts almost disappear. A conflict happens when two people change the same lines. Small, frequent merges mean changes overlap far less, and when they do, the conflict is a few lines instead of a few hundred.
2. Reviews get fast and honest. Reviewing a 30-line change is easy; reviewing a 3,000-line change means skimming and missing things. Small changes get reviewed properly.
3. The trunk is always close to live. Because main receives tested work daily, the team could deploy it at almost any moment. There is no "stabilisation week" where everything sits frozen.
4. Continuous delivery becomes possible. When every merge is small and tested, shipping it automatically is a small step, not a leap of faith. Teams that deploy many times a day are almost always trunk-based.

What it costs

None of this is free. Trunk-based development only works when the team has built the safety net first:

• Automated tests that run on every change. If a broken change can reach main, the model collapses, because everyone builds on that shared line. Tests are the floor under everyone's feet.
• Feature flags, used with discipline. Unfinished work must be hidden cleanly, or the team is back to waiting for "the big merge".
• A pipeline that deploys quickly and can roll back quickly. Fast shipping is only safe when a bad release can be undone in minutes.
• A culture of small pull requests. This is the hardest part. It means splitting work into slices that are reviewable in one sitting, which is a skill the team has to practise.

The trade-off is real: trunk-based development is the best model for products that deploy continuously — websites, web apps, APIs, internal tools. It is a poor fit for software that ships as numbered versions people install, such as mobile apps that pass through store review. Those teams usually prefer git flow, where a release is a deliberate event rather than a continuous stream.

Trunk-based development vs GitHub flow vs git flow

Trunk-based development is the strictest of the three:

GitHub flow already says "merge to main when ready, deploy right after". Trunk-based development tightens that to "merge at least daily, and keep unfinished work behind flags". For a fuller comparison of GitHub flow and git flow, read GitHub flow vs git flow.

What it means for a PM

If your team works trunk-based, three things change in how you read their updates:

1. "Merged" still means "live soon" — same as GitHub flow, but even more so, because merges happen every day and deploys follow automatically. Don't write an announcement for a feature the moment it merges; check whether it's behind a flag first.
2. Feature flags are your best friend. A feature can be "done" and merged while invisible to users. Ask "is it behind a flag, and when does it go to 100%?" instead of "when does it launch?".
3. There is no release moment. Features trickle out continuously. Marketing plans built around a big "v2.0" announcement need to be rebuilt around smaller, rolling updates — or around the moment a flag is switched on.

Trunk-based development also changes the risk conversation. Instead of "will this release work?", the question becomes "if this small change is wrong, how fast do we notice and roll it back?".

If you're new to Git entirely, start with Git for product managers, or jump straight into the free lesson on GitHub flow and the one on branches.

Key takeaways

• Trunk-based development = merge to main at least once a day, with small, short-lived branches and feature flags for anything unfinished.
• It works because small merges mean fewer conflicts, faster reviews and a trunk that is always close to live.
• It requires automated tests, feature flags, fast deploys and a culture of small pull requests — the safety net comes first.
• It suits continuously-deployed products (web, API, internal tools), not versioned software like mobile apps.
• For a PM, "merged" means "live soon", features ship behind flags, and there is no single release moment.

FAQ

Is trunk-based development the same as GitHub flow?

Not quite. GitHub flow merges each change into main when it's ready; trunk-based development adds a daily minimum and shortens branch lifetimes to hours. You can think of trunk-based development as GitHub flow taken further. See GitHub flow vs git flow for the full picture.

Do you need feature flags for trunk-based development?

Yes, in practice. The daily-merge rule only works if half-finished work can live safely on main without reaching users, and a feature flag is the standard way to do that. Without flags, the team falls back to long-lived branches, and the model stops being trunk-based.

Why merge at least once a day?

Because the cost of merging grows with time. A branch merged daily overlaps little with others, so conflicts stay small and reviews stay easy. A branch merged weekly has diverged from everyone else, which is exactly the painful "big merge" the model exists to avoid.

Does trunk-based development work for mobile apps?

Usually not. Mobile apps ship as numbered versions through store review, so a release is an event and users can't all be updated instantly. Those teams typically prefer git flow. Trunk-based development shines for products that deploy continuously from main.