Just like with plain git - in GitLab you can merge a branch that has multiple separate commits in it. And you can also merge (e.g. topical/feature) branches into one branch - and then merge that "combined" branch into main/master.
Though most teams/project prefer you don't stretch that route to the extreme - simply because it's PITA to maintain/sync several branches for a long period of time, resolving merge conflicts between branches that have been separate for a long time isn't fun, and people don't like to review huge diffs.
I guess what I'm saying is: for very large complex features, I don't want one big commit. I want to review a series of commits and then I want to have that series of commits persist in the history.
This is how Gerrit operates "natively" - the commit message and everything is part of the artifact under review exactly like the diff.
If the model is to squash an MR into a single commit before merging it, I'd then want to be able to have MRs that depend on each other.
techcode|12 days ago
Just like with plain git - in GitLab you can merge a branch that has multiple separate commits in it. And you can also merge (e.g. topical/feature) branches into one branch - and then merge that "combined" branch into main/master.
Though most teams/project prefer you don't stretch that route to the extreme - simply because it's PITA to maintain/sync several branches for a long period of time, resolving merge conflicts between branches that have been separate for a long time isn't fun, and people don't like to review huge diffs.
bjackman|11 days ago
This is how Gerrit operates "natively" - the commit message and everything is part of the artifact under review exactly like the diff.
If the model is to squash an MR into a single commit before merging it, I'd then want to be able to have MRs that depend on each other.