Merge Request, Review process and using comments in GitLab

We're currently evaluating the use of GitLab for our project and one thing we find slightly off is the comments when reviewing a merge request.

The problems starts when some comments were entered as part of the code review and a new commit was pushed to address these comments.

Both the comments made on the commits and those made on "Changes" panel are shown on the "Discussion" tab, but there's no indication that some changes around the same lines were made. Going to "Changes" panel and looking at the latest-to-base comparison - I get exactly what I'd expect (everything done on the branch thus far), but then we have no was to see that overlaid with comments made on the old commits or old review.

I was half-expecting that in the discussion panel I'd be getting another section under each comment showing what was changed in the code recently. That, or be able to access all the comments ever made in the "Changes" panel when looking at the latest, even comments made on older versions.

Is there something I'm missing here when it comes to GitLab review process and managing comments?

GitLab has evolved considerably since 2016, and the new 13.1 (June 2020) adds a feature which is relevant for your use case:

Mark any Design thread as resolved

When you receive lots of feedback on a Design, the number of comment pins can build up quickly!
As your discussion thread grows, it gets hard to know which discussions are complete and which still need work.

With 13.1, you’ll have the ability to mark any comment as Resolved to signify that it is now complete.

Even better — your resolved comment pins will disappear from the Design so you can focus on what’s left!

And, of course, if you need to revisit something, all of your resolved threads will be available in the Resolved Comment area at the bottom of the sidebar. From there, you can find them again and see which revision applied at the point of revision.

We think this will greatly improve your workflow so you can focus on what is important.

See Documentation and Issue

---

GitLab 13.5 (Oct. 2020) will add a clear distinction between merge-request participants ("assignee") and reviewers:

To bridge these gaps, GitLab 13.5 introduces merge request "reviewers," which easily allows authors to request a review as well as see the status of the review.
By simply selecting one or more users from the "reviewers" field, the assigned reviewers will receive a notification of the request to review the merge request.

This makes it easy to determine the relevant roles for the users involved in the merge request, as well as formally requesting a review form a peer.

Requesting a pull request review is already available for GitHub

---

With GitLab 13.7 (December 2020), you have a clearer definition of reviewers:

Reviewers for Merge Requests

Asking a colleague to review your code should be a routine part of contributing code, but it’s often needlessly complex.

A simple task like asking for a review can lead to confusion. For example, how should you ask? An email? Comment? Chat message?

Without a formal process, reviews can be inconsistent and hard to keep track of. Previously, an option was to assign a reviewer to a merge request, but even with this formality, both the author and the reviewer appeared in the same assignee field, making it hard for other team members to know who was doing what.

GitLab 13.7 introduces reviewers for merge requests, which allows authors to request a review from someone.
The new “Reviewers” field allows users to be designated as reviewers in a similar way to assignees. The reviewers receive a notification inviting them to review the merge request.

This provides a formal process for requesting a review and clarifies the roles of each user in a merge request.

Future iterations will include showing the most relevant reviewers for a merge request as well as a streamlined merge request approval flow that puts reviewers at the center.
You can follow along in the merge request reviewer assignment epic for more details.

See Documentation and Issue.

---

See also GitLab 14.6 (December 2021)

View inline the change that outdated a merge request thread

When addressing review feedback in merge requests, you often change lines your reviewers have commented on.
In those comment threads, GitLab indicates that new changes were made.

However, to understand if those new changes address the feedback, reviewers would have to navigate away from the context of the discussion.

Now, when viewing threads related to old changes, you can view the new changes directly in the thread.
This improved context helps you review faster and more accurately.

See Documentation and Issue.

---

And GitLab 15.3 (August 2022):

Submit merge request review with summary comment

When you finish reviewing a merge request, there are probably some common things that you do, like summarizing your review for others or approving the changes if they look good to you. Those common tasks are now quicker and easier: when you submit your review, you can add a summary comment along with any quick actions like /approve.

See Documentation and Issue.

---

GitLab 16.5 (October 2023) adds:

Resolve an issue thread

Long-running issues with many threads can be challenging to read and track.

You can now resolve a thread on an issue when the topic of discussion has concluded.

See Documentation and Issue.

---

GitLab 17.3 (August 2024) adds:

Resolve threads in tasks, objectives, and key results

You can now resolve threads in tasks, objectives, and key results, making it easier to manage and track important conversations. Resolved threads are collapsed by default, helping you focus on active discussions and streamline your collaboration workflows.

See Documentation and Issue.