Great video, as always! As I am starting to shift to this type of code review model its great to see how others are doing it in the real world.
Early in the video when Joe mentions that pull request messages should essentially be in the git commit message, he says that before opening a pull request they "try to get everything revised into one small, readable, commit". Does this mean that after working on a feature branch all commits are squashed into one before requesting a merge?
In the case that the answer to the above is "yes", I'm curious how others feel about that practice. Is there any sense that some meaningful meta-information about the feature is lost by consolidating commits? You get to see the overall change, but if one line item is "refactored this method name", without the sole commit that accomplishes that refactoring, the ability to easily detect what just that part of the feature affected is lost.
On a related git process note: if multiple people are working on a feature branch and it exists on origin, before opening a pull request do you rebase the feature onto master and force push?