I Started Using Stacked PRs - Now I Can’t Go Back

In today's video, we're going to look at a concept within version control that I honestly knew nothing about until recently. And since having to use it on real projects, I'm starting to see it more and appreciate it more. It's not new, but it is powerful. And you need to know about it if you want to grow in your career as a software developer. Nowadays, everything is AI, LLM, agents, tokens, and you begin to think that that's all there really is to this anymore. This is why we have a new category of people who have no clue how to program but are trying to build that next big production-grade app anyway using whatever AI solution they've chosen for the day. But for those who've been in the field for some time, you know that there's much more to it than just writing code. Working with a team of experienced developers building and maintaining real projects with code reviews in CI/CD inside of cloud environments. It requires a much bigger skill set than an LLM alone can accomplish. So today I want to cover a concept that I recently had to work with called stacked diffs or stacked pull request versus the typical git workflow that we all first learn to use. The many benefits of stacking, some hands-on examples, and some new tooling that help streamline some of the complexities that arise. Let's get started. This video is sponsored by Graphite. More on them soon. So what are stacked diffs? Well, diffs, if you've used version control at all, is simply just changes between two versions of code. Stacked diffs, or you can say stacked pull requests, involves stacking a series of small dependent changes on top one another. Now, why would you do this? Well, let's look at your typical Git workflow. You have a main branch. Say you've been given a task to build a teams feature so users can invite co-workers into a shared workspace. And it involves three dependent parts. Number one, some back-end database stuff like a teams table, teams model, whatever. Second, some API endpoints like a post and a get teams. And third, a front-end UI section where you list the teams and members. Now, you wouldn't do all of this in a single PR. That's too much for anyone to try and review. And these are different parts of the app. Backend, business logic, and front end. So, you would create at least three pull requests to get it all done. So, you create a branch off of main. Let's call it branch one. You write some code and then you commit and create a pull request. At this point, you hope that someone reviews it soon because the next part depends on this part. You can't really start the business logic until you get your backend PR approved and merged. So, you're really at the whim of this review in order to continue forward. So, you're right here waiting for your PR to be reviewed. Maybe you have to make a few changes after the review, then ultimately for it to be merged so that you can pull the updated code and begin with that next dependent part. If the PRs are independent, then you're fine. But when they depend on something else being merged first, you're at a standstill. Now, what stacked diffs give you is, as the pragmatic engineer put it, the ability to keep working on your main branch and worry about reviews later. You check out the main branch and start working on it. Make a small change and commit this as a diff or a very small pull request. You then continue working creating a second diff and a third diff and so on. So in this flow you check out a branch from master. Let's go back to our example to do the backend work. So you check out branch one. You add the DB table a model. When you're done you commit it and create the PR for review. But instead of waiting for that to be approved and merged, you go ahead and create branch two off of your work on branch one. You add your API endpoints and you commit that change as a new PR. Note that this will be dependent on the previous and will merge into the previous. You then create a branch 3 off of branch 2. You do your front-end UI work and then commit that as a new PR, which again depends on the previous and will be merged into the previous. So, your work here is almost async. You're not held up by PR reviews that can take hours, even days, but you are freed up to continue to the next thing. And you aren't tempted to create PRs that are too big or that include too many parts. With stack diffs, every commit becomes a code review essentially. And you might be like, "This sounds complicated and pointless. I'll just stick to what I'm used to." Well, it's one of those things. You don't know how efficient it is until you begin to use it regularly and then have to go back to the old ways. I saw a comment recently on one video that said, "Having worked with stacked PRs at Meta for 3 years, then moving to a company that doesn't have it, my productivity seemed to halt." Stacked PRs is one of those things you don't realize just how incredibly powerful it is until you've used it and it's taken away. Everything is 2020 in hindsight. Now, before I answer that burning question I know you're dying to ask about the potential chaos that can happen with such a model, let me mention this first. Stacked PRs is not a new thing. The idea of stacked diffs originated in open source software development practice where developers would submit a stack of patches for review. But over time it was adopted into internal tools like fabricator at Facebook. Uber uses this as well and critique which is Google's internal tool for stack diffs. But it just may be as it was with me recently that you have never used it and will be one day asked to in your career. And once you begin to use these, you'll see why teams adopt it because it's very efficient and it allows developers to move fast and not get blocked by other humans. Because often other humans take forever to get to your PR. In addition, Jared Palmer, SVP of GitHub, I assume that's senior vice president, tweeted, "Regarding stacked diffs on GitHub, after discussion with Taylor B, who is a principal software engineer at GitHub, we can implement stacked PR's PR groups already, but reststacking automatically fanning out changes from the bottom of the stack upwards would be wildly inefficient. To do it right, we need to migrate GitHub to use git refs blah blah blah." This will take some time, but has been green lit. So number one, stacked PRs already exist on GitHub. I showed you that already. You just create branches from other branches and merge PRs into PRs below them. But for GitHub, the restacking would be wildly inefficient and they need to implement some better ways to do this. But they have the green light to go ahead. So I see going forward the importance of nailing down this concept so that you can be informed. Now when they say reststacking, this is the big question you probably have that I alluded to earlier. In a stacked diff workflow, if you change the bottom PR, say PR one of five, then all the PRs above it, two through five, need to be restacked or rebased so that their base commits move forward. But you see the downside here. Imagine you have 10 commits stacked. You catch them all up based on the first commit changes, but then branch 2 PR has some changes and branch four has some changes and you have to again and again catch the parents up by rebasing. So what has happened is there's an appeal now for someone to step in and create a solution to relieve you of this complexity. We know that devs can be much much more efficient by stacking PRs, but need some sort of tooling to at the same time relieve this complexity of having to replay changes over and over to parent PRs to stay current. One tool that you've probably heard of out there that is gaining traction in this regard is Graphite. Graphite actually gives you, among other things, commands to restack the entire chain in one shot and automatically updates the corresponding PRs. Here's a sneak peek. Restacked or rebased all the way up the stack with one command. Pretty amazing. Let me show you how this works with Graphite. And by the way, you can try Graphite out for free. Link will be below. First, you install the CLI with Brew or npm. Authenticate to GitHub. and they actually provide you interactive tutorials walking you through how to use the CLI. But let's work through the stacking process again, but this time with the graphite CLI. We can check out the main branch with GT checkout main. GT is graphite CLI tool. And let's make a change to one of our files. And now we need to create a branch and commit these changes. Well, the command GTre will actually do this all for you. So gtcreate- a this will stage any modified files just like the normal all command and get and then do a dash m and include your commit message. It creates the branch, stages my changes and creates a commit all in one. Next we want to push this change or this commit and create a new pull request. Again this can be all done in a single command with gtsubmit and it opens up my new PR in the graphite UI. And of course, you can view this PR in GitHub, which it created, but Graphite gives you this interface to manage all of this better. Now, here's where traditional Git workflows hold you up at waiting for this PR to be approved or for a reviewer to request changes if your next move is dependent upon it. Well, with Graphite, GT treats stacking as a first class concept. Watch this. While that BR is awaiting review, I can run GT checkout, select the branch I want to check out, which is going to be the branch I was just working with, and then move on to my next feature stacked on top of my prior changes. So here, I'll make some new changes just to demo this. Then, as before, I run gtre- a- m include my message. Again, this creates the branch and commits allin-one command. Now, we need to push and create the PR. So we run as before GT submit but this time we add the flag stack which will also submit descendants of the current branch. I can view my stack locally with GT log short or I can open the PR in graphite with GT PR. Here I can assign reviewers, add labels, see diffs per file and many other very cool things here that we'd have to focus on in another video perhaps. But the big question is when that first PR gets reviewed and we have to make changes, how can we efficiently apply or rebase those changes onto our PRs up the stack? Here we just have one. So let me go ahead and create one more stacked PR on top of this. So we have a stack of three PRs and the very first one on the bottom needs some changes. So let's go ahead and say that on PR1 they wanted the dash out of the H1 and caps letters just for a simple change. Let's run GT Checkout and choose our bottom PR. So, let's make the change they suggest. And here's where the magic happens. Instead of having to rebase all the PRs in the stack to include that change you just made at the bottom, you simply run this. And I'll show you the manual commands first and then the big oneshot next. So, let's do a get add so I can add that file. Then I'll do a get commit and I'll add amend and no edit which essentially takes whatever is currently staged and adds it to the last commit but keeps the same commit message. And then here's the magic command that updates the other stacked PRs with this change. No individual rebasing needed at this point. I just run gt restack which will restack all the branches above it. And it tells us here restack the second branch on the first branch and restack the third branch on the second branch. And of course, the first branch doesn't need to be restacked. And if I move up my stack, you'll see these PRs have the change we made in the base branch. And then I simply run gtsubmit with the stack flag like we did earlier so that it updates all the PRs. And see how it's updating the PRs here. It's a huge timesaver. And then as promised, the add, commit, and restack can all be done with the GT modify command. So this command amends this change to the branch and restacks all the branches above it. The first branch now has the new changes that you made from your PR feedback. And the second and third and fourth and onward through your stack. And then if you need to update your open stacks with the latest changes from main, you can run gync. This command actually pulls the latest changes into Maine, restacks or rebases all your open PRs on top of the new changes in Maine, and then will prompt you to delete any local merged or closed branches. Now, what about merge conflicts? This is probably the next question in your head. It's great that we can restack easily given no conflicts, but what about conflicts? Well, when you run GT Restack, if there are conflicts, you'll be prompted to resolve them as you're used to. It will inform you of the conflict. you'll resolve that conflict, stage that file, then instead of doing a get rebase continue, you just run gt continue and the restack command will continue to work its way through the stack. You can also see this on gts sync as this command also restacks. And then finally to merge your stack, say it's all been reviewed, it's ready to go. You can run gttop to check out the top PR in the stack or you can just run gt checkout and choose that top PR. run gtpr to open up that PR in graphite, which by the way again is just representative of the PR that it creates in GitHub, but gives you many awesome options in one place. And here you can click merge to merge it all. Or if you wanted to, you could just merge the first part or the first and second part, whatever. But in this case, we'll just choose the top PR and have it merge it all. And we're done. And from here I can run gync which will prompt me to delete my local branches that are now merged and place me on a fresh checkout of main. Now Graphite offers some other really cool features that are out of scope of this video like a VS Code extension that lets you create and manage stacked pull requests visually right from your IDE. So this is something I like to do because I like to do most of my git commands in the IDE with the IDE interface. There's also AI code review, Slack notifications, AI chat metrics, and many other very helpful features for dev teams. Again, this is free to go and use. The link will be down in the description. Go try it out. So hopefully you now understand the benefit of stacked PRs or stacked diffs and you can now join in on the conversations and you can create and manage them yourself. I think we'll see much more usage of them, especially when GitHub starts making moves toward a more capable environment for it. If you have any questions about stack diffs, leave them down in the comments. If you found this video helpful, give it a thumbs up. If you haven't subscribed to the channel, consider doing so. And I'll see you in the next video.

You can try Graphite for free here: 👉 https://graphitedev.link/travismedia I recently started using stacked pull requests (stacked diffs) on real production projects, something I honestly knew nothing about until recently. And now? I can’t imagine going back to the traditional Git workflow. If you’ve ever been blocked waiting on a PR review, struggled with massive pull requests, or worked on a team with CI/CD and real production constraints this Git workflow is worth understanding. This isn’t theory. This is how experienced teams ship features incrementally without slowing each other down. Thanks Graphite for partnering with me in the video. Check out the Travis Media Community - https://travis.media/community ⏱️ Chapters 00:00 Intro 01:14 Why we need stacked diffs? 04:35 Stacked PRs is not new 05:22 GitHub in on board 06:15 Complexity of rebasing 07:06 Restacking in one command 07:34 Hands-on demo of how stacking works 12:11 But what about conflicts 13:50 Outro 🎥 Watch These Next 🎥 https://youtu.be/uDcb12CqoR4 https://youtu.be/EMWNZtCYg5s https://youtu.be/jUOysN-rcyQ FOLLOW ME ON Twitter - https://x.com/travisdotmedia LinkedIn - https://linkedin.com/in/travisdotmedia FAVORITE TOOLS AND APPS: Udemy deals, updated regularly - https://travis.media/udemy ZeroToMastery - https://geni.us/AbMxjrX Camera - https://amzn.to/3LOUFZV Lens - https://amzn.to/4fyadP0 Microphone - https://amzn.to/3sAwyrH ** My Coding Blueprints ** Learn to Code Web Developer Blueprint - https://geni.us/HoswN2 AWS/Python Blueprint - https://geni.us/yGlFaRe - FREE Both FREE in the Travis Media Community - https://imposterdevs.com FREE EBOOKS 📘 https://travis.media/ebooks #stackeddiffs #github #graphite #stackedpullrequests