LilyPond Contributor's Guide: 3.3.4 Merging to master

### 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 checkout 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”.

#### LilyPond — Contributor’s Guide v2.22.2 (stable-branch).