Skip to content

rikukissa/stacker

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

Build Status Sponsored

logo

Stacker

Because no one really reviews a 4000 line PR
Download the Chrome extension

TL;DR

YouTube intro

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

Features:


Motivation

Tweet

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:

scopes

  1. 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
PR's base is set to previous PR's branch





Upstream based pull request
Keeps the base as upstream and shares the commit history with its parent.


PR 2 is a sequel to PR 1.
For instance, in PR 1 you implement the tooling and boilerplate for localization and in the second one you add the localization itself.


PR 2 depends on the functionality proposed in PR 1, but the dependency doesn't go the other way.
They can be published as 2 separate pieces of functionality.

Parent based pull request

Pros

PR 2 is easily reviewable once the reviewer understands changes proposed in PR 1

  • The entire Github's PR view only shows changes made in PR 2.
  • 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.

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

PR 2 can accidentally be merged into a stale branch

  • If PR 1 gets merged first, failing to update PR 2'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

PR 2 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 PR 2 is a sequel for PR 1

  • ✨ 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.

PR 1 can get merged accidentally if PR 2 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

Pull request order visible in pull requests Select parent pull request

Only see changes made in the PR you’re reviewing

Only relevant changes visible

Automatic warnings of pull request dependencies

Automatic warnings on child pull requests

Related work


This project was bootstrapped with Create React App.

Thanks for reading πŸ™‚