In my experience the situation with GitHub is either that
- you apply the commits as-is on the target branch and end up with a ton of pointless "fix this" and "fix that" commits that were created during the review process,
- you squash everything and lose what might otherwise have been meaningful, useful commit boundaries for the purpose of bisecting, reverting or just investigating the history of changes or
- you rework your commits and force push changes to the branch you want to pull and create confusion as to what changed because that's not usually how review is conducted with GitHub.
I think the pull request is a bad abstraction. Not terrible, and certainly easy to grasp, but bad enough that everything you do with it is a compromise. At the very best, if you apply with the squash+rebase strategy and limit the scope of your PRs to what makes perfect sense as just one commit in the target branch, it's just a convoluted way of working with individual commits.
Comments
In my experience the situation with GitHub is either that
- you apply the commits as-is on the target branch and end up with a ton of pointless "fix this" and "fix that" commits that were created during the review process,
- you squash everything and lose what might otherwise have been meaningful, useful commit boundaries for the purpose of bisecting, reverting or just investigating the history of changes or
- you rework your commits and force push changes to the branch you want to pull and create confusion as to what changed because that's not usually how review is conducted with GitHub.
I think the pull request is a bad abstraction. Not terrible, and certainly easy to grasp, but bad enough that everything you do with it is a compromise. At the very best, if you apply with the squash+rebase strategy and limit the scope of your PRs to what makes perfect sense as just one commit in the target branch, it's just a convoluted way of working with individual commits.