Transcript
00:00:00GitHub have just released its biggest update in years, stacked PRs, a brand new way to break down
00:00:05massive PRs into more manageable chunks. In this video, we're going to cover exactly what they are
00:00:10and why you'd use them. Stacked PRs are a powerful but fairly simple concept. Break large code
00:00:21changes into a chain of smaller dependent pull requests. You can review and merge independently.
00:00:26To have a stack, you need two or more pull requests in the same repository where the first
00:00:31or bottom pull request targets the trunk, usually your repository's default branch such as main,
00:00:37then each subsequent pull request targets the previous. This forms a dependency chain where
00:00:42each branch builds on the one below it. Foundational changes such as shared types or database schemas
00:00:48go in the lower branches and code that depends on them such as API routes and UI components
00:00:53goes in the higher branches. And you may be thinking, well, I've always been able to do this, right?
00:00:58I could raise a PR to main and then raise a second PR to that PR and chain the PRs as much as I like.
00:01:04And that is absolutely true because in the context of just Git, there's no such thing as stacked PRs
00:01:09and you'd still just be daisy chaining PRs together. Only within GitHub itself, does stacked PRs actually
00:01:16mean anything. But they do bring some massive advantages. And if you want to stay up to date
00:01:22with tech and AI, then subscribe to better stack. So to make use of stacked PRs, it's best to have
00:01:27the GitHub CLI installed. And with that, you can run gh stack init and then declare your new stack.
00:01:33So let's go to our text editor and now we can go through an example of stacking multiple PRs.
00:01:38So the first thing we're going to do is run gh stack init setup database. So in this case,
00:01:44the PR or the branch is going to be called setup database. And this will be the base PR that's now
00:01:50going to point to main. Then we can make our changes. For the case of the demo, I'm just going to put
00:01:54changes into the readme file. So I said I implemented the database and then you can just do git add,
00:01:59git commit. So everything here is just standard git. And then when you're ready to switch to your next set
00:02:04of changes, you can then do gh stack, add, and then your next branch. Then I can make more changes,
00:02:10create the API endpoints. Maybe I want to add some extra points here. So I'll commit this change.
00:02:16Then we can add a second change as well. And then again, we can commit this. So as you would expect,
00:02:20you can make multiple commits per branch. And then finally, we'll do gh stack, add setup front end,
00:02:25and then make one more change here. And then again, we do git add and git commit. Now, once we're happy
00:02:31with all of our changes and we want to push all of those branches up to GitHub at the same time,
00:02:36we can just run one command, gh stack submit. This will then give us this mini CLI UI where we can go
00:02:42through each one of the PRs in the stack and add a title and a description if we want to. Or we can
00:02:48just press next on each one and then submit three PRs in one go. So you can see all three of those PRs,
00:02:55setup database, API, and front end have all been pushed to GitHub as a stack within a single command.
00:03:02And you can actually do all of this without the GitHub CLI. Just follow the old school method of
00:03:07linking PRs together manually from main to PR1 to PR2. Then GitHub will still detect these as a stack
00:03:14once you push them all up. The CLI just makes this much easier to manage. Now, remember nothing has
00:03:20changed within Git itself. If you want to check out a completely different branch that's not within the
00:03:24stack you're working on, you can do that and then just come back to the branch within the stack later.
00:03:29If we now head over to GitHub itself, you can see we've got each of our three PRs and they're raised
00:03:34as pull requests here. And you can see we also have this little stack icon here to tell us that these
00:03:39PRs are associated to a stack. If we open the tail PR, so the one that's on top of the stack, you can
00:03:45see down here, we can click merge stack and you can see this UI as well. So we can see every single
00:03:49PR as part of the stack. We could go through this and approve it one by one. But once we're happy with
00:03:54all of this, you can then just click merge stack and every single one of those PRs would be merged
00:03:59into main at the same time. You'll also notice that references to stacks are now integrated
00:04:03throughout the entirety of GitHub. So you can see them on the pull request page, on the pull request
00:04:09list page. You'll also see them on things like GitHub workflows and throughout really the entire
00:04:14application. So if you're working on massive PRs and you need an easy way to split that up
00:04:18into separate segments, you no longer need to wait for separate PRs to be merged into main
00:04:23and do all the rebasing and the merging yourself. You can just create one long stack and GitHub
00:04:28is now perfectly equipped to manage all of that within the UI. And the CLI is a really nice
00:04:33way to manage it all automatically. There's been an overwhelmingly positive response to this
00:04:38online. And particularly when used with AI, I think this can be a really powerful feature
00:04:43when you do things like design agentic loops and let the agent run for hours. It can now create
00:04:48stacked PRs and link all of that work together rather than creating either a massive PR or loads
00:04:54of completely separated PRs. But I hope you found this one useful guys. Let me know what you think
00:04:58of stacked PRs in the comments and subscribe to Better Stack to stay up to date with the latest
00:05:02tech and AI news. Thanks for watching. And of course, I'll see you next time.