In my team, we recently switched to a merge-request based workflow. The aim is to reap the benefits from code-reviewing.
The way we work right now is as follows:
- One person has a “master” project on GitLab.
- Collaborators fork this and submit merge-requests.
- The “master” reviews the code and attaches comments to lines using GitLab launching a discussion on that code-fragment.
- If the discussion is resolved due to a code-change, a collaborator adds a comment to the discussion referencing the commit hash in which the code was applied.
- The “master” reviews the commit in question and - if he’s happy with it - resolves the discussion.
The bullet-point in bold is unwieldy. The collaborator must manually get the hash and copy/paste it in the discussion.
We decided to do this to solve the following problems:
- When looking at the “changes” tab you only see the “latest” snapshot.
- When using the “Compare to Previous Version” button in the merge-request page and there are several pending discussions, it’s hard to tell which points were tackled in those new commits. As an example, a recent MR resulted in 12 separate discussions. The following push by a collaborator dealt with only 3 of those discussions. While manually matching the discussions with the latest commits is possible it’s unwieldy.
Having the commit-hash directly in the discussion allows the reviewer to immediately jump to the proposed changes.
We’ve looked to see if a commit-message or slash-command can somehow trigger a commit to be associated with a discussion, but could not find anything.
My question is: Is our workflow flawed? Are we missing something in GitLab that would make this workflow easier?