In Git, no branch is special.
After a Git installation, a single branch named master is created from which branches can be created and updated. But Git’s master branch isn’t special. It can be deleted at any point in time, and it has now special powers or capabilities that set it apart from any other branch in the Git wilderness.
However, despite the fact that there is nothing technically special about the master branch, there is something very philosophically special about it. In most development environments, the master branch is treated as a source of truth, it’s the branch where all all of the latest verified builds are stored and it’s a place that is protected at all costs from broken code. In the development world, the master branch is indeed special.
To recognize the special status of the master branch, GitLab assigns it default status and also marks it as protected. Only users in the developer or maintainer role can push a GitLab branch into master branch or merge a branch into the GitLab master. For those who have not been anointed with the appropriate rights, a merge request is required to merge a topic branch or feature branch into master on GitLab. In fact, GitLab even provides a “No one” option that can completely restrict any merge or push to a master. Indeed, the master branch is special.
How to merge into master
So how does an average, everyday user of GitLab merge code into the master branch? The answer is to issue a GitLab pull request.
A developer must log into the GitLab web application and create a merge request, specifying the branch they are working on as the source, and the master branch as the target. A user with rights to merge or push into the master branch is made then set as the assignee before the merge request is initiated.
The next time the merge request assignee logs into GitLab, they will be notifed. They can then proceed with the GitLab merge into master or reject the request. Regardless of the path chosen, the originator of merge request is notified.
Going beyond Git with GitLab
GitLab isn’t Git. GitLab uses Git under the covers, but it wraps the open-source version control tool with a number of fancy features and DevOps tooling to create a service that is more that just version control. The idea of protecting branches, assigning users roles and requiring merge requests is completely foreign to Git. But if you are interested in performing a GitLab merge into master of one of your feature branches, these are concepts with which you will need to become comfortable.
The source code and sample project used for these examples can be found on the gitlab-made-easy project page on GitLab.