Workflow for multi-commit review

How to Use GitLab
,
1

Hello,

I’m currently trying to switch from (an old version of) gerrit to gitlab (currently 12.9 ee) for code review.

I’m struggling a bit to adapt, and would like to ensure I’m not missing something.

With our gerrit setup, when one pushes a branch for review, each of them is
reviewed and cherry-picked independently from the others (but usually in order).

Each commit has a “Change-id: ${UUID}” line in the commit log.

When the author amends the commits to take review feedback into account and pushes (-f) another
version of the branch, the commits are different, but the change-ids are kept
untouched.
This enables gerrit to understand that some commits are actually different versions of the same change, and compare them.

This is really helpful. It encourages dev to split modifications into several
small commits which are easier to review. If the split is done proprely,
most of them won’t require several rounds of review and will be either frozen
or cherry-picked quickly, allowing the team to focus on reviewing remaining
ones.

For instance, if three versions of the branch are pushed like this

                A       C
    master -*---*-------*
             \  A'  B'  C'
              --*---*---*
                     \  C"
                      --*

On the first round of review, gerrit enables us to compare and comment on

master…A
A…C

then on the second round, on

master…A’ and A…A’
A’…B’
B’…C’ and C…C’

Comparing between C and C’ is very useful to see how the comments I made on
C were taken into account into C’

On the third round, one would only check on B’…C" and C’…C" (and maybe C…C").

I have found no way to review commit per commit gitlab:

  • it lets you compare between versions of a branch, but not between
    versions of each change.
  • the comments don’t show up on each commit page.

Is there a way to replicate our usual gerrit workflow with gitlab?

I guess we could send a single initial commit per MR, make amendments as isolated commits and squash them at the end, as recommended in [1].

That would work, but would slow down the process a lot, because we would have to wait for for the first MR to be merged before sending the next one.

Am I missing something?

I have not tested merge request dependencies [5] but I doubt it would help.
I’ve not tested gitlab 13 either. The new “commit navigation” [6] and “head comparision mode” [6] seem
useful, but I don’t think they’ll be enough.

Is there description of review workflow in gitlab besides [1], [2] (irrelevant), [3], [4] somewhere?

Thank you!

[1] https://docs.gitlab.com/ee/development/code_review.html
[2] https://youtu.be/XluG9mAQdSo?t=1395
[3] Code review workflow?
[4] https://www.almtoolbox.com/download/code-review-with-gitlab-06182020.pdf
[5] https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_dependencies.html
[6] https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/#commit-navigation-buttons-in-merge-requests
[7] https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/#new-comparison-mode-for-merge-requests

1 Like