How do you process a Gitlab merge request?

Question

I'm working with a small group of people on a project, using Gitlab. As not everyone is equally experienced (with both project development and git itself), we figured we would require merge requests to be sent before code could be merged into the main development branch. So far so good, this allows for an extra pair of eyes to skim the code.

The current workflow is a bit inconvenient, though, and it feels like it could be improved. When someone creates a merge request (via the Gitlab web interface), someone else navigates to Gitlab as well to see what is being merged, reads through the code, and then recreates the merge locally, on his own machine, to test it manually. Note that we don't have CI set up, as that is somewhat out of scope for this project. Then, when everything seems all right, he or she clicks the button to accept the merge request on the Gitlab page.

Especially the part where we recreate the merge locally just feels terribly clunky. These are only automatic merges, mind you, but still, it feels like double work.

What is a good workflow for dealing with merge requests in Gitlab? What could we improve? Is there a good way to recreate the situation that would exist after the merge, without actually committing to the merge yet? Or is there a way to make Gitlab detect a merge as 'resolving a merge request'?

Answer 1

If the person testing the merge locally uses the --no-ff flag when merging

git merge --no-ff branchname

Then if they test and like the result, they can push to the target, and GitLab will know to go and close the merge request.