> Rapid changes to a PR is bad etiquette. Submit a PR for review, await comments, when received, prepare fixes and submit a new iteration.
I think this depends a lot on context. GitHub now lets you open "draft" PRs, which are explicitly unmergeable until you mark them as ready. If I'm unsure of the approach I'm taking, it's helpful to be able to show my team what I have and ask for feedback before I've done the work to polish it to a mergeable state.
Surely I'm not the only one who finds this useful, or the feature wouldn't exist.
Furthermore, it's also helpful when collaborating on something that's not code via a PR. For example, I've used git to collaborate on documents; as far as I'm concerned it's much better to have a tight feedback loop between the comments I receive and the edits I make to the document. There's not one "right" way to word things, and I'm not necessarily the only one working on that document, I just happened to be the one to start it; allowing other people to suggest small edits to the document piecemeal more closely matches the kind of collaboration I'm actually looking for.
Even before Draft PRs existed, I would often encourage especially junior devs to open PRs early and just include a note (in the description or the first commit) with a "Work in Progress" or "Not Ready to Merge" type comment and then either delete that (if in the description) or add a new comment with "Ready to Merge" or similar when ready.
It's great to see GitHub add this as a real tool now, but there's always been lots of good reasons to open PRs early, evolve them rapidly with discussion, and merge them only once discussion converges. It can be a useful workflow for some types of teams.
That, in my experience makes it harder to review the change. To me, it's easier to do something like that while pair programming. Code review should be done once a final approach has been taken and only minor changes or factors that the implementation may not have taken into account should be addressed.
Most PR systems have multiple ways to "slice" the changes coming in to specific updates and giving you "bookmarks" for what you've reviewed prior and what is new in the latest update.
Just because it may not be your preferred workflow doesn't mean it isn't a useful workflow or that the tools don't already exist to make it a manageable workflow.
My experience with Github Enterprise is that I'll make a comment and someone will commit a change, but the reference to the change is far removed from where my comment text is (especially if there are many comments made between my commit and the commit that addresses it).
And if there are many other such commits addressing different comments, it gets difficult to find the one that specifically addresses the code I commented on.
So, I essentially need to skim through the diff again to find the code that I commented on, open another tab to find my comment and uncollapse it if it's outdated according to Github, and switch back and forth between the tabs to see if my change has been addressed. If it hasn't been addressed, I need to start a new comment thread on the updated diff.
I think this depends a lot on context. GitHub now lets you open "draft" PRs, which are explicitly unmergeable until you mark them as ready. If I'm unsure of the approach I'm taking, it's helpful to be able to show my team what I have and ask for feedback before I've done the work to polish it to a mergeable state.
Surely I'm not the only one who finds this useful, or the feature wouldn't exist.
Furthermore, it's also helpful when collaborating on something that's not code via a PR. For example, I've used git to collaborate on documents; as far as I'm concerned it's much better to have a tight feedback loop between the comments I receive and the edits I make to the document. There's not one "right" way to word things, and I'm not necessarily the only one working on that document, I just happened to be the one to start it; allowing other people to suggest small edits to the document piecemeal more closely matches the kind of collaboration I'm actually looking for.