A field guide to selective promotion
How a large engineering team shares one development sandbox — and still ships any single feature to production, on any schedule.
Most release models quietly force a choice.
Either every change is integrated and tested together — and therefore ships together, on one train, where a single delayed feature holds the rest hostage — or features ship independently and nothing is ever tested in the combination it will actually run in. Most teams pick one and absorb the cost of the other.
There is a third option, and it is the one large engineering organizations eventually need: a shared sandbox where everything is integrated and tested together, plus selective promotion that moves any single feature to production on its own schedule. Integration and release, decoupled. It buys per-feature deployment on any cadence — scheduled or urgent — without giving up integrated testing, and it makes release documentation a by-product rather than a chore. It is not free. The rest of this brief is what it takes to run the model without it collapsing under its own complexity.
One sandbox in. Any feature out.
This model earns its complexity for a large team shipping many features in parallel against a need for flexible release timing. A small team on a simple cadence does not need it — and should not take it on.
Integration is not release
Testing changes together and shipping them together are two different decisions. Most pipelines conflate them into one.
The unit of promotion is the feature
Not the branch, not the sprint. One ticket's worth of change, moved on its own and on its own schedule.
Design for the last five percent
Ninety percent of promotions are mechanical. The model lives or dies on how deliberately you handle the rest.
Four moves that hold the model together.
Selective promotion from a shared sandbox is a genuinely hard problem: a large team means parallel changes to the same files and to files that depend on each other. Four moves are what keep it from collapsing.
Merge queues into a long-lived trunk.
A large team committing into one shared branch will overwrite each other's work — quietly, and usually on a Friday. A merge queue is the fix: changes are serialized, and each one is tested against the current tip of the trunk before it is allowed to land. The shared sandbox stays releasable at all times, and no engineer's work is silently clobbered. This is the foundation — selective promotion built on an unstable trunk is not worth attempting.
An author-centric promotion model.
When you lift one feature out of a shared sandbox, every file it touches raises the same question: whose version is correct? The answer that scales is a rule, not a meeting — default to the changes made by the developer who owns the ticket being promoted, identified by their commit frequency on the trunk rather than by who opened the pull request. This single rule resolves roughly 90% of promotions with no human involvement. It is the entire difference between a model that runs and one that drowns in merge decisions.
Squash commits and cherry-picked hunks.
Mechanically, a promotion is a cherry-pick: find the squash commit for the ticket on the trunk, and apply that exact diff to a copy of the integration branch. Be clear-eyed that this deliberately bypasses git's own merge machinery — a squash commit carries no useful ancestry to perform a three-way merge against. That is a real trade. It buys a clean, per-feature unit of promotion; it costs git's automatic conflict resolution. Whether the trade is worth it depends entirely on the next move.
Route the hard cases to deliberate manual resolution.
Because the cherry-pick forgoes git's merge internals, a minority of conflicts cannot be resolved by any rule — two authors editing the same lines, a file renamed in one ticket and modified in another. The discipline is to not automate these into a guess. Detect them, retain the integration branch's lines as the safe default, and flag them for a person — with enough context attached that the decision takes minutes. The honesty of the model is that it names this last 5% out loud and routes it deliberately, rather than pretending a tool resolved something it has not.
Four branches, one promotion path.
The four moves compose into a single git topology. Work begins in the shared sandbox, where everything is integrated and tested together. Selective promotion lifts one completed feature at a time onto the ladder that leads to production — and each branch deploys to its own environment.
The sandbox holds everything. The integration branch holds only what was selected. That difference — and how cleanly you move a feature across it — is the whole model.
The edge cases you design for.
The author-centric rule clears most of the work. What remains is a small set of cases that no rule should silently resolve — because resolving them wrong is exactly how one engineer's work disappears. Three to design for deliberately:
New, renamed, and deleted files.
File-lifecycle operations are where selective promotion gets genuinely hard. A newly added file is easy — take the trunk's version wholesale, since no integration-branch version exists to conflict with. Renames and deletes are the hard case, especially when they span tickets or developers inside one release: a file deleted in one promotion and modified in another has no rule-based resolution. Treat file-lifecycle conflicts as first-class manual cases, not an afterthought the tooling will absorb.
Same-author versus multi-author conflicts.
The resolution rule branches on authorship. For a same-author conflict — the promoted change touches lines the same developer previously promoted — prioritize the newer change from the trunk; the author's latest intent wins. For a multi-author conflict — a different developer's already-integrated change touches the same lines — retain the integration branch's lines and flag for manual resolution. Never let a multi-author conflict resolve silently.
Schema and data changes ride a separate track.
Database changes do not cherry-pick like application code. Schema migrations and data corrections need their own selective-promotion track — applied per ticket, checksummed so an environment knows exactly what it has, and paired with a tested rollback. Treating schema change as just more code in the diff is one of the most common ways a selective-promotion model produces an environment no one can reason about.
A complex model the team does not have to feel.
Selective promotion combines trunk-based and release-branch development to move features agilely. That is real operational overhead — and it is exactly the kind of overhead that tailored tooling and agents absorb. Four high-leverage applications:
Conflict resolution, assisted
The edge cases that reach a human should arrive pre-investigated. Tailored CLI utilities and Claude Skills do the git archaeology — locate the competing commits, assemble the context, lay the two versions side by side — so the engineer spends their time on the judgment call, not on reconstructing what happened. The five percent stays manual; it does not stay slow.
Release documentation, automated
A selective-promotion model knows exactly which tickets are in a given release — that is its core data. An agent turns that manifest into release notes, version and tag artifacts, and documentation pages, written and kept current with no manual effort. Release documentation stops being the thing that is always slightly out of date.
Code review and test evaluation
As a feature is promoted, an agent reviews the exact diff being moved and evaluates whether its unit-test coverage is adequate — a quality gate that runs on the unit of promotion itself, not on a whole branch after the fact.
Pull request management
The model generates release and post-release pull requests as a matter of course. Agents open them, label them, attach context, and shepherd them — turning the PR mechanics of a complex release into something that largely runs itself.
A model this capable is not full autopilot, and a brief that claimed otherwise would not be worth reading. Selective promotion at scale still needs an experienced hand on releases — the occasional schema-changeset error, the genuinely novel conflict, the release that has to be managed. That is not a shortcoming of the model; it is what operating large-scale engineering looks like. The model's job is to make the routine routine, and to make the exceptions small, visible, and fast.
If features are waiting on a window —
If finished features sit idle waiting on a release date, or an urgent change cannot ship without dragging everything else with it, the release model is the constraint — and it is a fixable one. An hour is usually enough to know whether selective promotion fits how your team works.