Gitlab Merge Requests Easily Explained

Markus Günther 10.09.2015 Expert Topics

1 Comment // Reading Time: 9 min.

It has been some time since we have dealt with the subject of Gitlab. We have been using Gitlab at sgalinki Internet Services for a long time and we are very happy with it.

Contrary to all prejudices, as a developer I also enjoy attending conferences. Where else can you meet so many like-minded people in the short of time? Exchange is one of the most important things in today's fast-paced world and gives us the tools and inspiration to master our daily tasks.

I have already spoken with many colleagues from other companies at one or the other event and some discussions or questions arise again and again.

Questions like for example:

How do you manage the repositories?
Do you conduct code reviews and if so, how do you implement them?

Questions that are understandable. Not every small agency has the possibility to always use the latest technologies immediately. Often there is simply not enough time to deal with these topics. But versioning and code reviews are a topic that makes everyday work so much easier, so that the investment pays off quickly for the institution.

But how do we do it all now? To come back to the questions.

We at sgalinski Internet Services have been using the Git versioning system for quite some time and manage our Git repositories using the open source software Gitlab.

Not so long ago I wrote an introduction to Gitlab. Have a look at it if you are interested. Today, however, my article will focus more on merge requests.

Gitlab Merge Requests

Since version 2.0 Gitlab contains a feature called Merge-Request. Some will know Merge-Requests rather under the term Pull-Request. The platform Github uses this term and is very popular because of its wide distribution.

But technically, a merge request is nothing more than a pull request.

In a merge request, a developer or development team makes a request to merge a development branch into the main branch. This development branch can contain several commits.

Thus, the topic of merge requests only becomes really interesting if the development team works according to the feature branch workflow. For a merge request we need a different Git branch.

Do you want to talk to web development specialists at eye level?

Contact without obligation

Short description of the feature branch workflow

The master branch is also the central project history when working according to the feature branch workflow. But instead of committing directly to the local master, developers always create a new branch when working on a new feature.
Feature branches should have a clear and understandable name. Many companies have conventions for branch names. For example, a branch name could be composed as follows:

{type}-{2-3 words summary}-{ticket id}

According to this convention, we would have the following branch "feature-gitlab_merge_request-4711" for our blog article (which is also versioned in git).

Git makes no technical difference between the master and feature branches. This means that the developer can commit, stashen, and cherry-pick as they know it from working on the master branch. So you don't have any disadvantages, only advantages from the feature branch.

Feature branches, however, should not only be used locally. You push them to the central repository just as if you were working on the master. This is the only way that other developers in the team can work with you or test the feature. By the way, you also have a great backup of the local commits. After all, you never know what will happen to a computer.

So you are working on a project and have the task to develop a REST-API. In order not to hinder the other developers on the project, you create an extra Featue branch.

git checkout -b feature_rest-api-4711 origin/master

You can't share this development branch with colleagues yet, because it's only available locally. So the logical consequence would be to push it to the central repository right after creating it.

git push -u origin feature_rest-api-4711

Now you can work as usual and commit your work at regular intervals. Remember: "commit small commit often" and do a "git push" at the end of the working day at the latest.

So much for the feature branch workflow itself. But at some point even the most complicated feature is implemented and must find its way into the master branch. Here we come back to the actual topic of merge requests. Because a feature, like a REST API, should already be tested conscientiously and seen by more than one developer.

Does your company need a web specialist to talk to on an equal footing?

Create merge requests

Since we have now developed our feature and want to have it moved to our main branch, we create a new merge request in Gitlab. You could also merge the branch into the master yourself, only then you won't have a decent dialog with your colleagues. The Gitlab Merge-Requests can also be used for reviews.

Once you've pushed the branch, Gitlab has a button to create a new merge request. You can find this button under Projects, Activity, Files, Commits and of course directly at Merge Requests. So you can't miss it.

To create a new merge request you have to fill out the following form.

We have a quite simple user interface through Gitlab and can't really do anything wrong. The branches are preselected and usually we don't have to adjust anything here. Unless we clicked and wanted to create a merge request for the wrong branch.

In our case we want to have merged the feature-rest_api-4711 branch into the master. Therefore we only have to write a meaningful description of our adaptations. In this step, we also always note the steps to the successful setup. It can happen that the testers have to make adjustments to the database or other systems in order to be able to test a new feature. It is therefore important to give the colleagues all the necessary information so that they can test this new feature. It is also a good documentation for later use. You could also put this information in a Markdown file in the documentation directory of the project.

For the description of the merge request you can also use Markdown.

Besides the description of the actual process, you can assign the merge request to a colleague. The colleague will receive a notification that he should view and release the merge request. If it should be necessary that several persons should be notified, you can also notify further persons in the description with "/cc @all" or "/cc @sgalinski". However, they can then usually only vote for the merge request and not close it.

Once you've carefully completed and documented everything, just press the "Create Merge Request" button and the review process for your great REST API will begin.

We have assigned Jonas Quinn as the main person in charge and only he or you can accept the merge request now.
The other people who have received a mail from the CC can comment on the adjustments and vote with +1 or -1.

So even if Jonas Quinn didn't have time to do the review, you get feedback from the other participants and after many good evaluations you can accept the merge-request in good conscience.

Jonas Quinn finds some time with us and takes a look at the merge request and the commits. He can now express his criticism directly in the code diffs or as a normal comment on the merge request.

Through this kind of communication you can conduct very good and targeted code reviews. Other colleagues often see problems that you haven't considered yourself or have suggestions for improvements that can still be incorporated. A merge request is not finished when you have created it. Jonas Quinn's remarks can now be easily edited in his feature branch.

Or if there's nothing to customize, just answer them. After the feedback from Jonas our Merge-Request has been downgraded. With the comment :thumbsdown: Jonas made sure that the MR has a negative rating.

You can see this at the small symbol.

Since Markus had really documented very sparsely, this is now adapted with another commit in the feature branch. This commit is automatically displayed in the merge request.

Markus can now answer Jonas' comments and keep the discussion going. The goal is to deliver the best possible product and more than two eyes are usually important.

New commit and feedback — Figure 5: Feedback on new commit

You can see in the stream how the developers can easily discuss problems directly with the code. Jonas will now be notified about the current status and can evaluate the review again.

Jonas liked our adjustments, next to Nolan, who also switched on after his e-mail, and we can now merge. When rating, please make sure that the ":thumbsup:" or ":thumbsdown:" is given first in the comment and not at the end. Otherwise it will not be evaluated. The devaluation of Jonas has now been reversed by his ":thumbsup:" and our merge request has two good ratings.

Reviews of the merge request — Figure 7: Evaluations of the merge request

Now Markus can either accept the merge request himself, or he waits until Jonas does.
When accepting the MR there are still some things to consider:

We have documented a lot in the description of the MR to make it as easy as possible for the testers. But if we just press the green button, then we get a quite detailed commit message in our master branch. We don't want that and so we adjust the commit message afterwards.

We don't want to use the feature branch even after merging into the master, so we click on the checkbox to delete the source branch.

This should now look something like this. If so, we are ready for the last step. We click the "Accept Merge Request" button.

Gitlab will now automatically transfer the adjustments to the master branch, delete the feature branch for us, and if we have named a ticket, update the ticket (in this case close it).

As you can see we have successfully merged our REST-API into the Master and completed the feature.
I hope that with this article I could show you a little how to optimize your working process with Git and Gitlab.

We love Gitlab!

Contact us!

We are a digital agency, which is specialized in the development of digital products. Our core topics are websites and portals with TYPO3, eCommerce with Shopware and Android and iOS-Apps. In addition, we deal with many other topics in the field of web development. Feel free to contact us with your concerns!

Contact form