- Sydney Cohen
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
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.
- 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:
|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
Axolo is an incredible tool for connecting PRs with our everyday engineering discussion on Slack. It integrates seamlessly and makes it so as a manager, I never lose track of my engineers' work. For my engineers, it allows them to collaborate without losing a thread in different contexts. Overall it keeps us moving swiftly throughout the sprint and continuously reviewing and merging code!
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.
We used to send each other our GitHub PR links on Slack to ask for a review. Having Axolo made it a zero-effort thing. Having discussions on Slack is much more natural and Axolo does a great job doing it. The support is amazing as well! Arthur and Sydney proactively reach out to ask if we're facing any issues and even released one feature request within hours!