Post by Michael Smolyak


I have long been aware of use of Git merge requests as part of the development process. Last week I started using the technique myself and wanted to share the positive experience with my Next Century colleagues.

For those of you who are not well versed into this tool, merge request is a Git technique for combining the code from a feature branch with the trunk. On many open-source projects it has to be used since not everyone has commit privileges for the master branch. If you are not a committer, the only way for you to contribute to the project is to commit code into your feature branch and then request the committers to merge you code into the trunk.

This is not the case on my current project. All the team members can commit into any branch, thus the use of merge requests is purely optional. Here is how it works. After I complete the feature, I create a merge request based on the feature branch and assign it to my co-worker, typically one familiar with the feature. He, in turn, gets the notification about the merge request assigned to him. In effect, I ask him to inspect the code in the feature branch and, when he is satisfied, merge it into the trunk.

GitLab, the tool we use on the current project, has solid support for merge requests. Creating a request takes a single button click (GitLab shows you your feature branches and asks you whether you want to create merge requests from them.) The GitLab pane displaying information about the merge requests gives the reviewer information on the commits that are part of the merge request and, more to the point, shows all the changes made to the code on a per-file basis. The color-coded display shows all the relevant code snippets where the lines were remove, added or modified.

Another very useful feature of merge request screen is the ability to leave inline code comments. This allows the reviewer to leave comments attached to individual code lines, which are then immediately sent to the code author who may respond to the comments on the same screen. Once the author makes the necessary code changes and pushes them into the feature branch, the merge request screen will reflect the updates and will allow the reviewer to approve them.

The last step in this process is for the reviewer to merge the branch, optionally deleting the feature branch. The reason I find this back-and-forth between the reviewer and the developer so useful is because the incentives and tools of merge requests are well aligned to encourage good development practices such as code review, small feature branches and, most crucially, communication among the team members.

Code review is the integral part of the branch merging process – you as the reviewer do it not because there is a rule that says that your team shall do code review, but rather because you are responsible for merging a feature branch into the trunk. By clicking the Merge button, you are certifying that you’ve reviewed the code and are satisfied with it. Merge requests encourage relatively small and short-lived feature branches, since creating a feature branch with hundreds of lines of changes means asking your co-worker to stop what he or she is doing and spend hours reviewing your code. And to accomplish the merge, there are many informational exchanges between the author and the reviewer fostering application knowledge dissemination among the team members.

If your project does not yet use merge request, I would urge you to give the feature a try – you’ll be happy you did.