I get to use both Gerrit (rebase-cherrypick workflow) and gitlab (PR/MR workflow) at work.
I think that MR is better for smaller projects i.e. ~10devs - it's lower overhead, just commit while you work then write up a description when you push.
I think rebase-CP is better for larger projects like ~100 devs committing to a repo - linear git history and every commit having a clear description+purpose+review is worth the overhead at that point.
So one-off tools and infra and stuff get chucked into gitlab while "the product" is in Gerrit.
I've never really used Github's PR system, always something else, but once in awhile I stumble in there in there from an opensource repo and they seem impossible to read with the individual commits.
Why doesn't Github just flatten/squash the stack of commits visually? Like I don't care what they're doing inside .git, can't they just diff the latest commit against the base commit and display that? So it's visually merged even if it's not merged in git's log?
---
At my work we do single commit. I find it annoying to work that way, I sometimes try to make clones of certain commits so I can restore to that point if I need to, but for reviewing, having everything in one neat little bundle, it's nice.
I think that MR is better for smaller projects i.e. ~10devs - it's lower overhead, just commit while you work then write up a description when you push.
I think rebase-CP is better for larger projects like ~100 devs committing to a repo - linear git history and every commit having a clear description+purpose+review is worth the overhead at that point.
So one-off tools and infra and stuff get chucked into gitlab while "the product" is in Gerrit.