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

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.
  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 avoid this situation and check first if 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 the translation branch and release/unstable which cannot be force-pushed. For these cases, use the following procedure:

  1. Merge the branch manually using the command line. The example assumes no pending changes in the local master branch and merges the translation branch: 
    git switch master
git pull
git merge translation
git push origin HEAD: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”.
[ << Working with source code ][Top][Contents][ Compiling >> ]
[ < Patch countdown ][ Up : Lifecycle of a merge request ][]

<< Back to Documentation Index

LilyPond — Contributor’s Guide v2.23.82 (development-branch).