stacker

Stacker adds features to Github's UI which makes managing and reviewing pull requests easier.

Features:

Motivation

Reviewing and even creating pull requests on Github can sometimes be very frustrating. Especially when you're reviewing a PR so large that it becomes difficult to follow what is happening. A solution for this is to start thinking of pull requests as smaller increments than, for example a feature. Don't get me wrong, they should still be logical increments and not just some random blobs of commits, but the idea remains the same. They should be broken up into smaller pieces. Stacker is a Chrome extension that makes your life that tiny bit easier. It makes minor additions to Github's UI that help you visualize the pull request dependency structure.

If you are not familiar with the concept of stacked pull requests, jump right into "So what are stacked pull requests?" section.

Installation

1. Download the extension
2. Generate a new personal access token and add the following scopes:

3. Open up Stacker options by clicking the extension icon at the right-top corner of your Chrome window. You'll notice that access token field for github.com domain is empty. Paste your token there and you're all set! Notice that you can also add more domains. This plugin also supports enterprise GitHub.

So what are stacked pull requests?

As you start splitting your pull requests into smaller chunks, you come to notice that one PR's code is actually dependent on anothers, and you continue to work on top of the previous PR you made. This is completely fine, but the question now is whether you want to proceed with the Upstream based pull request and keep your second PR's base as upstream (master/develop, usually the selected by default) or set it to be the branch your previous PR uses (this is what I shall call a Parent based pull request).

Common pull request workflows

Parent based pull request

Pros

is easily reviewable once the reviewer understands changes proposed in

• The entire Github's PR view only shows changes made in .
• Reviewers are able to figure out which PR is a sequel to the PR they just reviewed. Adding [PART 2] type labels also makes this more prominent.

Cons

The first PR (parent) can only move forward after all child PRs are reviewed and ready to be merged.

• can't be merged to upstream before is reviewed and merged to .

can accidentally be merged into a stale branch

• If gets merged first, failing to update 's base before merging will lead it to being merged to a stale branch.

• ✨ This is when Stacker helps. It shows you a warning on the parent PR. For this initial release I've decided to just show a warning. Would disabling the merge button altogether be more useful? Create an issue if you have an opinion about this :).

Well, ok, it's quite bothersome to actually figure out the PR dependency tree

• ✨ Stacker actually fixes this with fancy labels on the PR titles, but more about that later on.

Upstream based pull request

Pros

Parent PRs can now be merged even when the children aren't ready

• Obviously depends a bit of the PRs you decide to make. As a side note, I really wanna bring up this great article about Feature Toggles and how they can help you deploy your to production even when it's still a bit unpolished. There are also couple of other really inviting benefits this approach offers, but I'll let you read about them yourself.

Cons

includes changes from both PRs making it more difficult to review.

• ✨ Yup, you guessed it. Totally want to fix this and this was actually the main reason I started writing this extension. In this case the extension changes Github's default "Files changed" - view to show you only changes from the pull request you're reviewing. Sweet!

There's no easy way of seeing that is a sequel for

• ✨ Stacker's colored labels on Github's "Pull requests" - view should help a lot with this. On top of this, each label has a number that helps understanding in which orders the pull requests should be reviewed.

can get merged accidentally if is merged first

• ✨ This is where the warning is shown on the child PR's summary.

Features

Mark pull request as dependent of your previous work

Only see changes made in the PR you’re reviewing

Automatic warnings of pull request dependencies

Related work

• Stacked Pull Requests: Keeping GitHub Diffs Small

• #959 Mark pull request as depending on another

• #950 Stacked Pull Requests

This project was bootstrapped with Create React App.

Thanks for reading 🙂