In Git, no branch is special.
After a developer installs Git, it creates a single branch named master 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 no special powers or capabilities that set it apart from any other branch in the Git wilderness.
However, even though there’s nothing technically special about the master branch, there’s 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 the latest verified builds are stored and it’s a place that’s protected at all costs from broken code. In the development world, the master branch is indeed special.
GitLab recognizes the special status of the master branch. The platform assigns it default status and marks it as protected. Only users in the developer or maintainer role in GitLab can merge branch into master or push a GitLab branch into master. For users who haven’t been granted 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
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, specify the branch they’re 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 then set as the “assignee” before the merge request is initiated.
The assignee will then be notified of request the next time they log into GitLab. They can then proceed with the GitLab merge branch into master or reject the request. Regardless of the path, the originator of merge request will be notified.
Go beyond Git with GitLab
GitLab isn’t Git. GitLab uses Git under the covers, but it wraps the open-source version control tool with several fancy features and DevOps tooling to create a service that’s more than just version control. The idea of protecting branches, assigning users roles and requiring merge requests is completely foreign to Git. But if a developer is interested in performing a GitLab merge into master of one of the feature branches, these are concepts with which they’ll 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.