As developers, we use pull requests (PRs) to propose changes to the codebase. Occasionally, this peer-review process requires a significant time investment, leading to delays and stale branches. In this video, we’ll go over how you can curate your commits using interactive rebasing to more efficiently get your reviewer up-to-speed with your changes and avoid unnecessary delays in the PR process.
Note: If you haven’t yet watched Advanced Techniques in Git, be sure to watch the section on Interactive Rebasing first.
Chapters
Guiding Principals on Commit History What are some of our closely-held principles regarding our repository’s commit history? In this section, we’ll talk about our perspective that guides some of our practices and take an in-depth look at the feature branch lifecycle.
Curating Your Commit History Before Reviews One of the best ways to onboard your reviewer to your changes is to guide them through your thought process. We can edit the commit history using interactive rebasing before a PR is reviewed. In this section, we’ll talk about how you can organize your commit history in a way that more efficiently onboards your reviewer to your thought process and reduce the time it takes for them to get up-to-speed on your proposed changes.
The Review Process (As a Reviewee) When you submit a PR, there are things you can do to make the process easier for your reviewer. In this section, we’ll talk about some practices that can make the review process easier for the person assigned to review your PR, like curating your commit history and addressing change requests using commit SHAs. We promise your reviewer will thank you.
The Review Process (As a Reviewer) When you’re assigned to review a PR, your goal is to expeditiously provide thoughtful and meaningful feedback without sacrificing quality. In this mini section, we’ll go over some quick tips that you, as the reviewer, can use to improve the PR review process.
Curating Your Branch Commit History for Main Now that your code has been approved, it’s merge time! But before your feature branch is merged into main, you should consider editing your code’s commit history one last time using interactive rebasing. In this section, we’ll go over how curating your commit history for main is different than curating it for your PR.
Resources Section
Looking for more information? Check out these helpful resources:
In “Stop Giving Depressing Code Reviews,” Bryan offers his take on how to give people-focused PR reviews that balance critical and positive feedback.
In “GitHub Pull Requests for Everyone,” Catherine discusses how you can set up your pull request to make you and your team happy.
Looking for some inspiration for a PR template? Check out Sparkbox’s PR template in The Standard.
Curious about the Conventional Commit specification that we use to write our commit messages? Head over to Conventional Commits for the full spec.
Writing a good commit message is a big deal. In “How to Write a Git Commit Message,” Chris outlines seven rules to follow to write good commit messages.
