Yeah, me too. This is one of (if not the most) important practices you should do to make the PR review process quick. A quick PR review process in turn speeds up the shipping of code => business moves faster => greater chances of success for the company.
Always make your commits nice before asking for a PR review!
do you look at individual commits when doing a review? because the diff view shown is just the comparison of the trees, the history itself is irrelevant.
I do look at individual commits of the PR, yeah. Sometimes it makes sense to split up a task into multiple commits, or include refactor work, and that work should not be combined IMO.
Yeah, me too. This is one of (if not the most) important practices you should do to make the PR review process quick. A quick PR review process in turn speeds up the shipping of code => business moves faster => greater chances of success for the company.
Always make your commits nice before asking for a PR review!
do you look at individual commits when doing a review? because the diff view shown is just the comparison of the trees, the history itself is irrelevant.
I do look at individual commits of the PR, yeah. Sometimes it makes sense to split up a task into multiple commits, or include refactor work, and that work should not be combined IMO.
I agree. I'm not the greatest at this (often solo dev on things), but it's a good skill to know.