[alecbz]

> Do people actually do code reviews per commit?

This is sort of a meaningless question without an understanding of how often people commit. Some people keep a single commit for a single PR (and just constantly update that one commit), others make tiny little commits for every individual change.

The only real question is: what is the granularity you should review code changes at? The number of git commits that that maps to doesn't really matter.

IMO: the ideal is to try to keep pull requests as small as possible while still having each PR be a coherent, justifiable change on its own. I don't know if it's realistic to treat that as a hard rule, but I think it's the right thing to aim for.

[angrais]

Yes, but the OP asked if people are reading specific commits in a PR.

The answer for me at last is no. Because the history in a PR should not matter but only the final commit. That's why we choose to squash commits in my current role.