Trunk-Based Development Vocabulary: Feature Flags, Short-Lived Branches, and CI
Trunk-based development, short-lived feature branches, feature flags for incomplete work, and continuous integration vocabulary.
If you work on a team that ships software frequently, you have likely heard phrases like “keep your branches short-lived” or “we use feature flags for that.” These ideas come from trunk-based development, a branching strategy favoured by high-performing engineering teams at companies like Google, Facebook, and Netflix. Understanding the vocabulary around this workflow will help you participate confidently in code reviews, sprint planning, and architecture discussions — whether your team already practises it or is considering the switch.
Core Terms
Trunk-based development — a source-control workflow in which all developers integrate their changes into a single shared branch (the trunk) at least once per day. The goal is to reduce the pain of merging and to keep the codebase in a continuously releasable state.
“We moved to trunk-based development last quarter. Merge conflicts dropped by about 80% because nobody has a branch older than a day.”
“Our onboarding docs say we practise trunk-based development, but half the team still has feature branches that are two weeks old. We need to have a conversation about that.”
Trunk (main / master) — the single long-lived branch that represents the current, authoritative state of the codebase. In modern repositories it is usually called main; older projects may still call it master. Either way, the trunk is the branch that every developer merges into and pulls from daily.
“Always pull from
mainbefore you start work. The trunk changes fast here.”
“Your PR can’t be merged until it’s rebased on the latest trunk. There were three other merges this morning.”
Short-lived branch — a feature or fix branch that exists for hours or, at most, one to two days before being merged back into the trunk. The shorter the lifespan, the smaller the diff and the easier the review.
“We enforce short-lived branches through a bot that flags anything older than 48 hours. It’s a bit aggressive, but it keeps the backlog of open PRs manageable.”
“I’ve only been on this task for a day and the branch is already getting long. I should probably split it into two short-lived branches and ship the refactor separately.”
Feature branch lifespan — how long a feature branch exists before it is either merged or abandoned. In trunk-based development, teams actively monitor and minimise this number, treating a long lifespan as a risk indicator rather than a sign of thoroughness.
“What’s the average feature branch lifespan on your team? Ours crept up to nine days last sprint and our merge queue became a nightmare.”
“Reducing feature branch lifespan was the single change that most improved our deployment frequency.”
Integration and Merging Vocabulary
Merge frequency — how often a developer integrates their work-in-progress back into the trunk. High merge frequency (multiple times per day) is a hallmark of trunk-based development and correlates strongly with faster delivery and lower incident rates.
“I try to keep my merge frequency at least once a day. Even if the feature isn’t done, I integrate what’s safe to ship.”
“The DORA metrics report flagged our merge frequency as low. We average 2.3 merges per engineer per week; the elite benchmark is closer to once per day.”
Continuous integration (CI) — the practise of automatically building and testing every change merged into the trunk, typically within minutes. CI servers like GitHub Actions, CircleCI, or Jenkins run the test suite on each commit and report back whether the build is green or red.
“CI caught a null-pointer exception that none of us noticed in review. That’s exactly the safety net we need before we can increase merge frequency.”
“Our CI pipeline takes 22 minutes. Until we get that below 10, engineers won’t run it on every commit.”
Green build requirement — a team rule that no change may be merged into the trunk unless all automated checks pass (the build is “green”). This ensures the trunk always represents a working, deployable state.
“We have a hard green build requirement. If you break the build, you either fix it immediately or revert. No exceptions.”
“The green build requirement sounds strict but it actually reduces stress. You’re never second-guessing whether
mainis in a deployable state.”
Pull request size guidelines — team norms or automated rules that limit how many lines of code a single PR may change. Smaller PRs are reviewed faster, merged sooner, and carry less risk. Common guidelines cap PRs at 200–400 lines of meaningful change.
“Our PR size guideline is 400 lines max. Anything bigger needs a design doc first and a conversation with the team before you write the code.”
“I noticed your PR is 1,200 lines. Can we split the database migration out into its own PR? That way reviewers can focus on the logic separately.”
Feature Flags and Branching Models
Feature flag (for unfinished work) — a configuration switch that allows code for an incomplete or experimental feature to be merged into the trunk while remaining invisible or inactive for end users. Also called a feature toggle. Instead of keeping a long-lived branch, the developer ships dark code behind a flag and removes the flag once the feature is complete and validated.
“I’m using a feature flag so I can merge my half-finished payment redesign into
mainwithout affecting production. The flag is off for all users until QA signs off.”
“Feature flags let us decouple deployment from release. We ship the code when it’s ready to ship, and we release the feature when the business is ready to release.”
Release toggle — a specific type of feature flag used to control whether a completed feature is visible to users in production. Unlike a work-in-progress flag, a release toggle is switched on deliberately as a business or product decision, often used for gradual rollouts or A/B testing.
“The dark mode feature is code-complete and behind a release toggle. Marketing wants to announce it next Tuesday, so we’ll flip the toggle then.”
“We keep release toggles in a separate config namespace from work-in-progress flags. That way the ops team knows which ones are safe to enable without talking to engineering first.”
Branch by abstraction — a technique for making large-scale changes to a codebase (such as replacing a library or redesigning a module) without keeping a long-lived branch. The developer first introduces an abstraction layer that both the old and new implementations can sit behind, gradually migrates callers, then removes the old implementation and the abstraction layer once migration is complete.
“We used branch by abstraction to swap out our ORM. The migration took three weeks but every commit went straight to
main. Nobody else on the team was blocked.”
“Branch by abstraction is harder to explain to stakeholders than a feature branch, but once you’ve used it you never want to manage a three-week merge conflict again.”
Ship / Show / Ask branching model — a lightweight decision framework for how to handle a change. Ship means commit directly to trunk. Show means create a PR for visibility but merge it yourself without waiting for approval. Ask means create a PR and actively request review before merging. Teams use this model to reduce unnecessary review bottlenecks while keeping high-risk changes under scrutiny.
“We adopted the Ship/Show/Ask model and it cut our time-to-merge in half. Typo fixes and minor refactors go straight to trunk; new API endpoints go through Ask.”
“Not sure whether this counts as Show or Ask — I’m adding a new endpoint but it’s well-tested and follows our existing pattern exactly. I’ll mark it as Show and ping the team on Slack.”
Code freeze alternative — a strategy used instead of halting all commits before a release. In trunk-based development, teams avoid traditional code freezes by maintaining a continuously releasable trunk. If a risky change is in flight, it is hidden behind a feature flag rather than blocking everyone else from shipping.
“We don’t do code freezes any more. If something isn’t ready for the release, it goes behind a flag. Everyone else can keep shipping.”
“The old code freeze used to last four days before every release. Now our release process is 20 minutes and we ship whenever we want.”
Monorepo CI — continuous integration configured for a single repository that contains multiple services or applications. Monorepo CI requires careful configuration to run only the tests relevant to changed code paths, otherwise every commit triggers an hours-long full-suite run.
“We moved to a monorepo last year. The trickiest part was configuring monorepo CI so that a change to the payments service doesn’t trigger a full rebuild of the frontend.”
“Nx and Turborepo both have good support for monorepo CI. They cache build artefacts and only re-run tasks whose inputs have changed.”
How to Use These in Conversation
Scenario 1 — Explaining a long branch in a standup:
“I know my branch has been alive for three days, which is longer than our guideline. The change touches the auth layer and I wanted to be careful. I’m going to split it: I’ll merge the abstraction today, and the actual auth swap will go behind a feature flag so it can land tomorrow.”
Scenario 2 — Pushing back on a large PR during review:
“This is a solid piece of work but the PR is 900 lines. Can we agree on a split? I’d suggest merging the domain model changes first — that part is safe and self-contained — and then following up with the API layer in a second PR. Smaller diffs also help us stay within our pull request size guidelines.”
Scenario 3 — Discussing a release plan with a product manager:
“The feature will be code-complete by Thursday. We’ll ship it behind a release toggle. You can choose when to flip it — doesn’t have to align with our deployment schedule at all. We can also do a gradual rollout: 5% of users first, then 100% if metrics look healthy.”
Scenario 4 — Onboarding a new engineer:
“We practise trunk-based development here. The main things to know: keep your branches short-lived — ideally merged same day — and make sure CI is green before you ask for review. If you’re working on something big, use a feature flag rather than sitting on a branch for a week. Any questions about the Ship/Show/Ask model before you open your first PR?”
Quick Reference
| Term | Plain English Summary |
|---|---|
| Trunk-based development | Everyone integrates into one shared branch, at least daily |
| Short-lived branch | A branch that lives hours, not weeks, before merging |
| Feature flag | A config switch that hides unfinished code from users in production |
| Release toggle | A flag switched on when the business is ready to release a feature |
| Branch by abstraction | Replace a large component incrementally, all on the trunk |
| Continuous integration | Auto-build and test every commit, catch breakage immediately |
| Green build requirement | No merge allowed unless all automated checks pass |
| Ship / Show / Ask | Decision framework: commit directly, show for visibility, or request review |
| Pull request size guideline | Team rule capping how many lines a single PR may change |
| Monorepo CI | CI configured to run only relevant tests in a single multi-service repository |