Sliced Promotion When Dev Is Far Ahead of Main
Jul 02, 2026
When development has moved far ahead of production, promoting a small, already-accepted change can look straightforward—until you discover that the "normal" route would carry hundreds of unrelated paths with it. The work is small. The risk is accidentally converting a four-file promotion into a full branch merge.
The problem
The surface request is simple: get an approved workflow or configuration slice onto main. Branch policy says changes reach production through dev → main. That path is familiar and often correct.
The hidden problem is divergence. If dev is hundreds of paths ahead of main, a standard dev → main pull request may satisfy policy while failing scope. You are not promoting four files—you are promoting everything dev contains that main does not.
That creates a false choice: merge all of dev (unsafe) or do nothing (also unsafe, because the approved slice never reaches production). The real requirement is a third route: promote only the approved slice, with proof that nothing else came along.
What actually happened
A baseline audit established the scale of the gap: dev was far ahead of main across hundreds of changed paths, while the intended promotion was isolatable to a handful of workflow configuration files.
The item category was sliced release promotion—not implementation, not dependency remediation, not a broad reconciliation. The authorized write surface was exactly those workflow files. Everything else was explicitly out of scope: application code, API surfaces, UI, docs, lockfiles, migrations, infrastructure config, and deferred policy decisions.
Governance, not implementation, carried the complexity:
- Normal branch policy expected dev → main.
- A true dev → main PR was unsafe because of unrelated divergence.
- The safe route required branching from main, not dev.
- That route required a single-use branch-policy exception.
- Verification had to distinguish expected policy failure from real scope failure.
The technical steps were simple but high-stakes: branch from main, apply only the approved files from dev, prove the diff contained exactly those files, then open the promotion PR. Success meant the workflow changes were present on main and no other dev divergence was promoted.
Residual risks were classified explicitly: pre-existing dependency-scan findings accepted as out of scope; the branch-policy exception marked single-use and exhausted on merge; incidental whitespace normalization accepted inside the pinned file set.
The lesson
Promotion items are not the same as implementation items. Small diffs can carry large governance risk when branch divergence is wide.
Three facts matter before you start:
- How far dev and main have diverged — not just "there are changes," but a count of paths and whether the intended slice is isolatable.
- The exact authorized file list — written down, binary, with explicit non-goals.
- Which route is scope-safe — a normal merge PR may be policy-compliant and still wrong.
For workflow-slice promotion, the key evidence is not "PR opened" or "checks mostly passed." It is "the diff contains exactly the approved files, no extras."
When verification fails, classify carefully. A dependency scan finding may be pre-existing and out of scope. An end-to-end failure on first run may warrant wait-and-rerun rather than premature acceptance. Scope failure and accepted risk are different categories.
The broader principle
Sliced promotion is the right mechanism when dev is far ahead of main but a specific safe slice needs to reach production.
A temporary branch from main can be scope-safe but policy-exception-requiring. Treat branch-policy exceptions as single-use, item-specific, and exhausted on merge, close, or abandon—they must not become reusable precedent.
Human acceptance gates should authorize merge eligibility, not automatically perform merge or closeout. Acceptance is not execution. Closeout should require merge evidence before it runs.
Verification output should distinguish: passed clean; passed with named exceptions; blocked pending rerun; blocked for scope failure; blocked for unaccepted risk.
How to apply it
For similar future promotions:
- Start with current main, current dev, a broad diff count, and an exact allowed file list.
- Run a no-op check: if the slice is already on main, stop.
- Define an explicit stop condition if the diff expands beyond the approved list.
- Require a single-use branch-policy exception before creating a non-dev PR to main.
- Make diff proof binary: exactly approved files, no extras.
- Treat first-round E2E failures on main promotion as wait/rerun by default unless strong evidence shows they are unrelated and already accepted.
- Keep dependency remediation separate unless the item is specifically a security or dependency item.
For teams running governed delivery workflows, add a canonical sliced-promotion template and a standard branch-policy exception block: applies only to this item/slice, does not authorize broad dev → main, does not apply elsewhere, expires on merge/close/abandon.
The goal is not clever git gymnastics. It is preventing an accidental broad merge while still getting an approved slice to production—with evidence that proves you did exactly that and nothing more.
