A few months ago, I published The Power of a Conversational Code Review Culture. I talked about the importance of being generous with your code examples. Using GitHub’s built-in suggestions or posting diffs with the changes you have in mind go a long way towards helping the Pull Request’s author. It makes it easier for them to understand your suggestion, and include it in their code.
If you’re the reviewer and you already do this, kudos to you! Today I’d like to focus on the point of view of the Pull Request author.
So you’ve just received suggestions alongside your last code review. Lucky you! Here are a few things you can do next.
Thank the reviewer for their suggestion
It makes your job easier, let them know that!
Use the GitHub’s built-in tools to commit their suggestions to your branch
You can do that right from the GitHub interface. It’s quick and easy.
Apply their changes to your local copy and commit them
Copy the diff they posted, create a new
xx.diff file in your local checkout, and
git apply xx.diff. You’ll be able to test the changes on your machine right away, just like the reviewer intended.
When the time comes to commit those changes, you have 2 options:
Commit their changes in their name
If you are committing the changes exactly as they were suggested by the reviewer, use git’s
author flag to change the author of your commit:
git commit --author Name. Name is the git information (name and email address) of the PR reviewer. If you don’t know that information, you can find one of their commits in your codebase and examine it to find the author info:
Another solution is to find one of their commits on the GitHub website, and add
.patch to the end of the URL. You’ll find the exact same info as above:
Commit the changes with multiple authors
If you’ve made some changes to the reviewer’s suggestion, you can still credit them when the time comes for you to commit, thanks to
GitHub has a support document to introduce that option, but in short, you’ll want to add the following on the last line of your commit message:
Now I can hear you say: why would you go through the trouble of doing all that? It’s not a particularly straight-forward process and takes a minute. Nevertheless, I think giving props is a really important part of working as a team. It only has advantages:
- It clearly marks the reviewer as the author of those changes. If someone has questions about those specific changes in the future, they’ll know who to turn to.
- It gives pointers to future contributors; they’ll know who in the team is knowledgeable about that part of the codebase.
- It shows the reviewer that you appreciate the time they spent helping you, by giving credit where credit is due.
- It encourages others to chime in with their own reviews. Folks in your team and other passersby in your repository will see that contributions are encouraged and rewarded.
Invite reviews and contributions ➡️ Healthier codebase ➡️ Happier team