Member-only story
3 Helpful GitHub Review Tips
Tips for improving your review process
Git and GitHub are very powerful tools, and they make the lives of us developers much easier. However, because GitHub has so many features it can also be very overwhelming to use, and you most likely do not know all the ins and outs of the tool yet.
I don’t know about all its features yet, and I use it every day!
While reviewing pull requests on GitHub I have made some small discoveries that really helped me a lot, and I would like to share them with you here.
1. Split Diff (Difference) View
When you review a pull request on GitHub the default setting is set to show the code differences in a single unified file. The existing and new code are squished together with the existing being on top and the proposed changes below as seen in the screenshot below.
However, many IDEs often display the differences side by side. For some developers, such a view is easier to comprehend. Personally, I really like a split view when I deal with merge conflicts. Luckily, GitHub can also portray the differences in a split view as seen in this next screenshot.
In order to choose between the two different views, you simply click on the small gear icon as shown here:
2. Display Only the Newest Changes (Changes Since Last Review)
Once the author of a pull request has made adjustments to their code, after someone has reviewed it the first time, it is natural to request a second review.
GitHub kindly points out which files have been changed since you last reviewed them using the yellow outdated tag. This will let you know to take a look at them again.
