Our three-person team is moving extremely quickly at an early-stage company, with each person opening roughly 40–50 pull requests per day. As that pace increased, our merge process started breaking down. We originally required every pull request to be up to date with the main branch before merging, but constant updates made branches stale almost immediately and left people waiting for long periods. We have reduced the amount of pre-merge CI and moved more testing after merge, which improved throughput but feels risky. Has anyone dealt with a similar level of change volume? What merge strategy, CI setup, or workflow helped without creating a huge queue or sacrificing too much confidence?
4 Answers
At this volume, it may be worth reconsidering whether every change needs to land independently on main. Create short-lived batches that are reviewed and merged together, then run the full CI/CD process once per batch. Keep the batches small enough to roll back easily. You can still let developers work independently, but the integration point becomes a controlled release rhythm instead of hundreds of separate freshness checks. Measure post-merge failures and rollback time so you can tell whether the extra speed is actually worth the risk.
The biggest problem is probably requiring every branch to be current with main before merging. Every merge invalidates everyone else's checks, creating a self-inflicted queue. Keep pre-merge checks small and deterministic, then use a merge queue or batched merge process to run the important integration checks against the actual order of changes. Expensive suites can run after merge with automatic alerts and a quick rollback path. If the queue becomes the bottleneck, split checks into must-pass and deferred suites rather than making the queue run everything.
Before changing the workflow too much, optimize the CI itself. Run jobs in parallel, cache dependencies, use shallow checkouts, filter jobs by the files changed, install only what each job needs, and use stronger runners for expensive tests. Also cancel stale runs when a newer commit supersedes them. Track setup time, actual test time, queue time, and reruns separately so you know whether the real issue is compute, redundant work, or waiting for branch freshness.
I would keep a small required suite before merge and run the broader confidence suite asynchronously. That preserves a fast feedback loop without pretending every pull request needs the entire test matrix before it can move.
A lightweight trunk-based workflow may fit better than treating every change like a long-lived branch. Keep changes small, merge frequently, use feature flags for incomplete work, and batch changes when running the full integration suite is expensive. You can also group related commits into internal releases every few hours instead of forcing every tiny change through the entire pipeline immediately. The process should match the maturity of the product; don't build a large release system before you actually need one.
Stacked branches can help when changes genuinely depend on one another, but they won't solve a required-check storm by themselves. If the queue is already overloaded, adding more layers may make the waiting and rebasing worse.
That was our experience too: the merge queue helped with correctness, but only after we made the required job much smaller. Otherwise it just moved the bottleneck from individual pull requests into one giant line.