Rethinking Code Reviews with Stacked PRs

The first PR should address a small, self-contained unit of work. It should be reviewable on its own, even if it doesn't fully implement the desired functionality.

Reviewers should focus on the specific changes introduced in the first PR and provide feedback. Once approved, the PR is merged into the main branch, establishing a base for subsequent PRs.

Each subsequent PR builds upon the previous one, introducing new changes that rely on the code introduced in the earlier PRs. This approach ensures that each PR is a logical continuation of the previous one, simplifying the review process.

Reviewers should focus on the specific changes in each subsequent PR, ensuring that they are well-integrated with the existing code and that the functionality works as expected. After approval, each PR is merged into the main branch.

Once all PRs in the stack have been merged, it's essential to perform a final verification to ensure that the complete feature or bug fix is working correctly.

Tools and Techniques for Stacked PRs

While the core concept of stacked PRs is simple, there are several tools and techniques that can further enhance this approach:

A well-defined branching strategy is crucial for implementing stacked PRs. Consider using a feature branch for the entire feature development, with individual PRs branching off from the feature branch.

For example:

main
└── feature-branch
    └── pr-1
    └── pr-2
    └── pr-3

Git rebase can be used to clean up the commit history of PRs within a stack, making the review process more efficient and reducing merge conflicts.

git checkout feature-branch
git rebase -i main

Extensive automated testing plays a vital role in ensuring code quality and facilitating efficient reviews. Tests can be run for each PR, guaranteeing that the changes introduced do not break existing functionality.

Code review tools such as GitHub, GitLab, and Bitbucket offer features that can streamline the stacked PR workflow, including:

• PR Dependencies: Allow you to specify dependencies between PRs, ensuring that PRs are reviewed and merged in the correct order.
• Review Comments: Enable threaded discussions and annotations on code, facilitating focused feedback and collaboration.
• Continuous Integration: Automate the build, test, and deployment process, providing immediate feedback on the quality of changes.

Example: Implementing a New Feature

Let's consider a scenario where we need to implement a new feature in a web application. This feature requires several changes across different components of the application.

Step 1: Define the Feature

The feature is "Add a new search bar to the website." This involves updating the frontend, backend, and database.

Step 2: Create the First PR

The first PR addresses the frontend changes: updating the HTML template to include the search bar and adding the necessary CSS styling.

PR 1: Update Frontend with Search Bar

This PR can be reviewed and merged independently, as it doesn't rely on any backend or database changes.

Step 3: Create the Second PR

The second PR focuses on the backend changes: creating the API endpoint for handling search queries and processing the results.

PR 2: Add Search API Endpoint

This PR depends on the frontend changes introduced in PR 1, as the frontend will need to make requests to the new API endpoint.

Step 4: Create the Third PR

The third PR deals with database changes: creating the necessary tables and indexes to store the search data and support efficient queries.

PR 3: Update Database Schema for Search

This PR depends on the backend changes introduced in PR 2, as the API endpoint will interact with the updated database schema.

Step 5: Review and Merge PRs

Each PR is reviewed and merged sequentially, building upon the previous PR. Reviewers can focus on the specific changes introduced in each PR, ensuring that they work correctly and integrate seamlessly with the existing codebase.

Step 6: Final Verification

Once all PRs are merged, the complete feature (the new search bar functionality) is tested thoroughly to ensure that everything works as expected.

Best Practices for Stacked PRs

To maximize the benefits of stacked PRs, follow these best practices:

• Break Down Work into Logical Units: Ensure that each PR addresses a well-defined, self-contained unit of work, independent of other PRs in the stack.
• Keep PRs Small: Aim for PRs that can be reviewed within a reasonable timeframe, typically under 200 lines of code.
• Use Clear Commit Messages: Write concise and informative commit messages that accurately describe the changes made in each PR.
• Encourage Active Reviewers: Assign reviewers who are familiar with the codebase and the specific functionality addressed in the PR.
• Provide Clear Documentation: Include relevant documentation and test cases for each PR to facilitate understanding and review.
• Communicate Effectively: Use the PR discussion section for communication, questions, and feedback, ensuring that all team members are kept in the loop.
• Monitor and Adapt: Regularly assess the effectiveness of the stacked PR workflow and make adjustments as needed to optimize the process.

Conclusion

Stacked PRs represent a valuable approach to code reviews, offering numerous advantages over traditional workflows. By breaking down large changes into smaller, manageable units, stacked PRs improve review efficiency, enhance clarity, and encourage collaboration. This approach helps teams deliver high-quality code faster and with reduced effort.

By embracing stacked PRs and following the best practices outlined above, software development teams can significantly streamline their code review process, improve code quality, and enhance team productivity.