You just finished writing the new checkout flow for your shopping app, and now you need to add a promo codes feature. Promo codes are built on top of the checkout flow, but you realize you can’t build on top of the checkout flow because your first pull request hasn’t landed yet — it’s stuck in code review. In other words, you’re blocked.
What are you to do? You could:
Or, you could stack.
Ready to learn more about stacking?
Jump ahead:
Stacking is the best-kept secret of high-performing developers. The principle is simple: once you’ve finished writing a feature, you commit it to your feature branch, move it up the branch for review, and create a branch off of that feature branch.
Hold on, you’re saying — we always branch off of main. Why would I branch off of a feature branch?
The answer is fairly straightforward. Branching off of a feature branch allows you pick up your work where you left off. No need to wait for that feature to land, just branch and go.
Over at Graphite, we recently wrote about how to build Wordle using stacking. Here is a PR building all of Wordle all at once.
And here is a stack of eight that does the same thing:
As a reviewer, which of those two was easier to read? Which one are you likely to review faster? Which one do you think will get merged first? Let us know what you think in the comments section.
Now, I’m sure you’re asking, will this confuse my teammates?
Good question! And no, this will not confuse your teammates. GitHub thankfully has basic inbuilt support for stacks.
Let’s say you have a stack going: main → checkout → promo_codes. To create that stack, you can create two pull requests on GitHub:
promo_codes into checkoutcheckout into mainOne branch merges into the branch below it in the stack, and as a result, GitHub will only show the diff between those two changes, allowing your reviewer to understand the stack in bite-sized pieces.
When you merge checkout into main, you’ll automatically re-target the second pull request to now merge into main.
Two things we’ve seen others do to help their teammates understand their stack:
If this last bit sounds like a burden, this is where automated tooling can help, which we’ll discuss in a separate section.
While GitHub’s code review tooling has basic support for stacking, it still isn’t as easy out of the box as it is with Phabricator or Gerrit, where stacking is common. Most people don’t stack because the local tooling for it isn’t great — in GitHub, if you need to edit the pull request at the base of a stack, rebasing the upstack ones can be a lot of work.
Fortunately, much of that work can be automated, and there are many tools that help manage that work. Before starting Graphite, we used git-town, ghstack, branchless, and others.
Graphite was a tool purpose-built to bring this workflow to GitHub. It syncs your stacks, adds comments to GitHub to help orient your reviewers, and you can start using it today, even if your coworkers on GitHub aren’t ready to change their workflows.
The usual workflow has you fold your code into the first PR. With stacking, you can break up your changes into multiple PRs, which allows you to:
Furthermore, you can get more and more granular about feature releases once you start breaking apart your changes. Our example checkout flow sounds like a complex feature — at the least, it could be split into multiple pull requests, one for the server changes and one for the client changes.
Regardless of what you use, if you want to be a faster developer, just start stacking.
Install LogRocket via npm or script tag. LogRocket.init() must be called client-side, not
server-side
Learn more →
$ npm i --save logrocket
// Code:
import LogRocket from 'logrocket';
LogRocket.init('app/id');
// Add to your HTML:
<script src="https://cdn.lr-ingest.com/LogRocket.min.js"></script>
<script>window.LogRocket && window.LogRocket.init('app/id');</script>
useEffectEvent: Goodbye to stale closure headachesDiscover why the useEffectEvent Hook is important, how to use it effectively, and how it compares to useRef.
Shadcn CLI 3.0 takes component management to a new level. With namespaced registries, private access, and AI-powered discovery, it’s now faster and smarter to build React UIs.
Zod’s flexibility comes at a cost. This article breaks down why Zod is slower than AOT-compiled validators like Typia, and how to fix it with a build-time optimization that brings production-grade performance.
Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the October 15th issue.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
