Stacked Pull Requests

A Workflow to Stay Unblocked and Develop Quickly

Imagine that you’re a software developer for a social media company. Your company has posts, and now wants to add comments and reactions. Comments are responses to posts, and reactions are responses to comments.

The Problem with Large Pull Requests

As a diligent developer, you put up a Git pull request (PR) for the comments feature. Let’s say you want to add about 2,000 lines in your PR comment; in this scenario, you have a few options. 

1. Add reactions to the comments PR. This makes the PR longer and even less likely to be reviewed.
2. Bother a reviewer to accept your PR so you can merge it and continue developing. In this case, you’ve interrupted your teammate’s workflow and requested an expedited review, causing the risk of bugs being incorporated during a lower-quality review. 
3. You could move on to work on something else. 

Because the current model of feature branches requires that you branch off the main branch, developers can feel blocked when they need to Git merge code back into the main project. 

Many developers don’t know there’s actually a hidden option number 4 here: what if you didn’t have to branch off main? What if, instead, we branched off the comments branch and started the reactions branch?

To go even further, do you even need to make comments on pull requests at all? In most cases, the comments describe a set of related changes: one to the database, one to the server, and one to the client. What if you could break those up into individual PRs? 

Stacked Pull Requests

This would lead to a set of smaller pull requests, which have well-understood benefits. According to the GitHub Pull Request author’s guide, smaller PRs lead to:

1. Better reviews, because reviewers are less likely to get frustrated and blind stamp.
2. Faster merges, because reviewers will be able to review faster.
3. Fewer Git merge conflicts, because less work means there’s less to conflict with.

All of this sounds pretty ideal, so why isn’t the stacked pull request workflow more common? There are a few reasons:

1. Git rebases are a nightmare. The biggest blocker, by far, is what happens if you need to change a PR that you branched off. If you do that, any dependent branches need to be rebased onto the new branch, and any branches dependent on those need to themselves be rebased.
2. It’s hard to keep track of dependencies. For both the author and reviewer, once you start managing stacks with a height of three or more pull requests, it can become hard to remember where a PR is located.
3. How do you merge many things at once? And how are you supposed to do that with modern code review tooling? You can merge one, have to rebase upstack to be on it, and then merge the next.

The good news is that there are quality developer tools that can help manage a stacked pull request workflow.

There are many tools to manage stacks; for example, Graphite will automatically handle rebasing for you, visualize the stack, and provide automation for merging a stack. 

More important than using any specific tool is to just start stacking your changes so you can write smaller pull requests, receive better reviews, and ship features faster.

Get Stacking with Graphite & GitKraken Client

In addition to using Graphite to manage stacked PRs, consider adding GitKraken Client to your toolbelt. Interactive pull request management allows you to review, comment, merge, and approve pull requests without leaving the app.