alt Hacker NewsWho is creating a separate PR for each commit on their feature/fix branch?
sounds like crazy town.
I just dont understand why someone would operate like this.
Lets assume you're squash merging your feature branchs to your local main, then you're raising the them as prs.
why would you do this?
Replies
I haven’t used this project but I have used Gerrit. It has its drawbacks (like terrible UX) but its style of code reviews were the most sensible and commit of every PR might not be as bad as it sounds. GitHub’s PR reviews are atrocious and it’s unfortunate they have become the gold standard.
In Gerrit, you commit every review, and the author has to edit individual commits to address them (using git rebase). This may sound PITA but it makes the history absolutely clean, and makes it easier for both reviewers and authors to review and address suggestions.
On Github, on the other hand, reviewing a large PR is just insanely hard. Making sure comment was addressed properly is hard as well, they can get lost in a sea of suggestions. They also become separate commits instead of being part of the commit itself. The commit should always been treated as unit of work rather than the branch.
This is standard practice in the "stacked diffs" world: one review, one commit.
1 commit == 1 reviewable unit == 1 PR == 1 CL == 1 feature == 1 fix is a perfectly reasonable way of working.
I used to work at companies where no one squashed their commits and the entire git logs were filled with 80% non-sense like "temp" or "bad" or "working" with the other 20% being coherent changes. What's the point of doing this I ask?
Why would you have more than one commit for a PR? That sounds like crazy town.
On large teams I think the "cherry pick" workflow (Gerrit style) beats the "pull request" workflow (GitHub/gitlab style). On smaller teams it's the other way around. I think it's somewhere around 10-20 people actively committing that the cherry pick workflow comes out ahead.