It’s the end of the year, a time for reflection, eggnog, and everyone’s favorite: code freeze. For many dev teams, Q4 ends with a strict period where no new code changes are allowed to be made to the project. The rationale is straightforward: keep the main branch stable, minimize risk in production, and guarantee no new bugs sneak into critical end-of-year deployments. However, the practical downside is that engineers often find themselves blocked. You can’t merge any new changes into main, production pipelines are paused, and your teammates may not even be around to review your code. In the last few weeks of the year, your tech debt can balloon while the backlog piles up.

Stacking provides a way around this, allowing you to parallelize review and development so you can remain unblocked and writing new code even when your pipelines are frozen solid.

How stacking works

Stacking, initially popularized by large tech companies like Meta (Facebook) and Google, is an alternative to the traditional Git flow branching model. Instead of bundling an entire feature or refactor into a single, monolithic PR, stacking allows you to break your work into a sequence (or “stack”) of smaller dependent PRs.

Once each PR in the stack is reviewed and approved, you can either land them separately or all at once. Stacks of small PRs are easier to write, easier to review, and faster to merge.

Deliver faster after a freeze with stacked PRs

During a code freeze, when merges to the main branch are restricted, stacking lets you keep working without delays. For example, instead of being stuck waiting for an in-flight PR to merge, you can create a new branch on top of it. Because these branches are independent of main, you can continue coding, testing locally, and running CI/CD on the stack. Your stack of small PRs stays quarantined until deploys are unblocked, which means changes are isolated and ready to merge when the freeze is lifted.

While you could achieve a similar effect by putting all of these changes into one massive feature branch, large PRs are harder to review, take longer to merge, and can introduce more risk to production. With stacking, you'll have smaller, more manageable PRs ready to review, rather than one monolithic PR. This means your changes can be merged quickly and with minimal friction, ultimately accelerating your delivery timeline when the freeze is over.

Smaller PRs ease the pressure leading up to a code freeze

Stacking not only keeps code authors unblocked but also simplifies reviews, which is especially valuable during fragmented engineering time, like around the holidays. Massive PRs with thousands of changes are often delayed or skimmed, which increases the risk of hidden bugs and rushed decisions during a code freeze. By scoping each branch to a concise unit of change—ideally under 50 lines of code—stacking facilitates faster, more thorough reviews. When regressions do happen, it also makes debugging and rollbacks easier. Defects can be isolated to a small, focused subset of changes, making a rollback of 40 lines far simpler than 400.

Stay warm and ship fast with stacking

As the year winds down, stacking offers a simple way to keep development productive, even in the face of code freezes and end-of-year challenges. By breaking work into smaller, reviewable units, you can maintain momentum, simplify collaboration, and reduce the risks associated with large, monolithic changes. While stacking is particularly great during a code freeze, it doesn't just have to be a year-end thing. In fact, writing small, atomic PRs that are easier and faster to review is a practice that can keep your teams unblocked year round.

Don’t wait until next year’s code freeze; start stacking today with Graphite.