Managing Stacked PRs

Table of Contents

1. What is a Stacked PR? A Strategy for Sequential and Manageable Code Reviews
2. The Importance of Stacked PRs in Streamlined Code Reviews
3. Stacked PR in GitHub: How to Manage Stacked PRs
Creating a Stacked PR
Creating a Dependent PR
Merging Stacked PRs
Best Practices
4. Stacked PR Tools Tools available for managing Stacked PRs
5. Conclusion: Summary and Key Takeaways

1. What is a Stacked PR? A Strategy for Sequential and Manageable Code Reviews

The image contrasts two approaches to software development. On the left, a team works together smoothly, each piece of their puzzle represents a small, easy-to-manage pull request, symbolizing efficient collaboration and clear progress. On the right, a developer is overwhelmed by a jumble of puzzle pieces, illustrating the confusion and complexity of handling a large, unwieldy pull request. This visual metaphor highlights the advantages of stacked pull requests: quicker reviews, fewer bugs, and a more organized codebase.

A Stacked Pull Request (PR) is a development workflow strategy where multiple smaller PRs are opened in a specific sequence, each one building upon the previous. This approach allows for easier code review, as each PR contains a manageable chunk of changes, making it simpler for reviewers to understand the context and impact. Stacked PRs are particularly useful in larger projects where a single PR could become overwhelming to review.

2. The Importance of Stacked PRs in Streamlined Code Reviews

Stacked PRs align well with the best practices of having small, manageable changes in each pull request, as advocated by Google's engineering practices. Here are some key reasons why this is important:

Quick Reviews: Smaller PRs are reviewed more quickly, making it easier for both developers and reviewers to allocate time.
Thorough Reviews: The limited scope of smaller PRs allows for more thorough and focused code reviews, reducing the chances of overlooking critical issues.
Reduced Bug Risk: With fewer changes to consider, it's easier to assess the impact of the code, thereby minimizing the risk of introducing bugs.
Less Wasted Work: In case a PR is rejected, smaller changes result in less wasted effort on both sides.
Easier Merging: Smaller PRs are less likely to result in merge conflicts, simplifying the integration process.
Better Design: The manageable size of small PRs makes it easier to maintain good design and code health.
Unblocked Progress: The self-contained nature of small PRs allows developers to continue working on other tasks while awaiting reviews.

By aligning with the principle of making small, focused changes, Stacked PRs inherently incorporate these best practices into your development workflow.

3. Stacked PR in GitHub: How to Manage Stacked PRs

Managing Stacked PR as a developer

Managing Stacked PRs in GitHub can be a game-changer for your development workflow. According to a LogRocket blog post, here's a simplified guide on how to manage Stacked PRs in GitHub:

Creating a Stacked PR

Checkout the Base Branch: Start by checking out the base branch, usually master or develop.
```
git checkout master
git checkout -b feature-branch
```

Make Changes and Commit: Make your changes and commit them.

echo "Hello, World!" > hello.txt
git add hello.txt
git commit -m 'Add hello.txt'

Push and Create PR: Push the changes and create a PR against the base branch.
```
git push -u origin feature-branch
```

Creating a Dependent PR

Checkout the First Branch: Make sure you are on the first branch.

git checkout feature-branch
git checkout -b feature-branch-2

Make Changes and Commit: Make additional changes and commit them.

echo "Hello, again!" > hello2.txt
git add hello2.txt
git commit -m 'Add hello2.txt'

Push and Create PR: Push the changes and create a PR. This PR will be dependent on the first one.
```
git push -u origin feature-branch-2
```

Merging Stacked PRs

Direct Merge: Use the "Merge" option to maintain the commit history.

Best Practices

Labeling: Label the PR as 'Stacked' to avoid confusion.
Order of Merging: Merge the base PR first to simplify subsequent merges.

By following these simplified steps, you can manage Stacked PRs in GitHub more effectively, making your development process more organized and efficient.

4. Stacked PR Tools Tools available for managing Stacked PRs

Managing Stacked PRs can be made even more efficient with specialized tools. Below is a table summarizing some of the popular tools and their features:

Tool	Features
ghstack	- Submit stacks of diffs as separate PRs - Supports Python 3.8+ - Easy setup with GitHub Personal Access Tokens
Git Town	- High-level CLI for Git - Supports common branching models like GitHub Flow, Git Flow - Simplifies Git commands
Sapling	- Intuitive UI - Git integration - Methods for stacking, iterating, and submitting work
Spr	- Client-side script integrated into Git - Simplifies branch and PR management - No special server-side software needed
Graphite.dev	- GitHub sync - Pull request inbox - CLI with stacking & simplified commands - VS Code extension

Axolo is a Slack app to help techteams review pull request seamlessly

5. Conclusion: Summary and Key Takeaways

Stacked PRs offer a more organized and efficient approach to code reviews, especially for larger projects. They align well with best practices for small, manageable changes, making the review process quicker and more thorough. Various tools like ghstack, Git Town, Sapling, spr, and Graphite can further streamline this workflow, each offering unique features to manage your Stacked PRs effectively.

By incorporating Stacked PRs and these tools into your development process, you can significantly improve code quality, reduce review time, and ultimately, deliver better software.

If you liked this article you might also like: How to review code in GitHub.

Axolo User Experiences

2480+ developers online

Dan

Axolo has made it easier to hold developers and QA engineers accountable for reviewing and merging pull requests on a timely basis. Our average PR time-to-merge was 2.40 days before Axolo, this has been reduced to 1.51 days after only using it for 2 weeks.