[ << Working with source code ]	[Top][Contents]	[ Compiling >> ]
[ < Patch countdown ]	[ Up : Lifecycle of a merge request ]	[ Abandoned patches > ]

---

3.3.4 Merging to master

Before allowing a merge request to be merged, GitLab ensures the following:

1. The merge must be fast-forward. In most cases, this can be achieved by ‘rebasing’ the branch with the most recent commits from master. This can be handled via GitLab, if no conflicts arise. Otherwise, or if preferred, the operation can be performed locally.

   Please don’t combine a rebase operation with changes of the merge request! Do it in two steps instead (usually first committing changes to the merge request, then rebasing). This makes it easier to review the changes.

2. The (possibly rebased) changes must have passed automatic testing. This ensures that the master branch is always clean and ready for development and translation.

After rebasing, GitLab will immediately start the automatic testing pipeline. At the moment, all steps may take up to one hour to complete. If you are confident about the rebased result of your changes, you may click “Merge when pipeline succeeds” to avoid waiting for the tests. On failure, the merge will be aborted and no harm is done to the master branch.

Because GitLab enforces fast-forward merges, this means only one set of changes can be rebased and merged at once. A second merge request would be rejected later on because it does not contain the commit(s) merged first. To avoid wasting testing resources, please prevent this situation by checking first whether a pipeline with a scheduled merge is already running. View the list of merge requests and verify that no merge request with Patch::push status has a blue “timer” icon.

How to merge a branch without rebasing

It is generally recommended to rebase commits before merging to get a linear history. However, this is not always possible or wanted. This particularly holds for translations and the release/unstable branch, which cannot be force-pushed. For these cases, use the following procedure:

1. Merge the branch manually using the command line. The example merges the dev/translation branch, assuming no pending changes in the local master branch:

   git switch master
   git pull
   git merge dev/translation
   git push origin HEAD:dev/translation
   

2. Open a merge request at GitLab. This will immediately trigger automatic testing as described above.
3. Accept the merge request once the testing finishes, or use the button to “Merge when pipeline succeeds”.