... | ... | @@ -75,10 +75,8 @@ Finally, the *Changes* tab shows the patch itself. This view may be restricted t |
|
|
|
|
|
## Merging your merge request
|
|
|
|
|
|
We use GitLab's [merge train](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/) functionality to automatically rebase and merge branches to `master`.
|
|
|
After your merge request has been reviewed and approved it can be added to the merge queue by pressing the "Start merge train" button:
|
|
|
|
|
|
![start-merge-train](uploads/fe0ffa99f68f0a9134f5292393505682/start-merge-train.png)
|
|
|
We use @marge-bot to automatically rebase and merge branches to `master`.
|
|
|
After your merge request has been reviewed and approved you can request that it be added to the merge queue by @-mentioning @reviewers. Your MR should be added to the merge queue within a day or two.
|
|
|
|
|
|
As long as your MR satisfies the following, GitLab will batch your MR with other MRs and attempt to merge into `master`:
|
|
|
|
... | ... | @@ -90,4 +88,4 @@ Each batch is an MR and must pass CI, so you can expect GitLab to merge two or t |
|
|
|
|
|
### Rebasing
|
|
|
|
|
|
You generally do NOT need to rebase your MRs unless there are merge conflicts with `master`. GitLab will automatically rebase on top of `master` when batching MRs. |
|
|
You generally do *not* need to rebase your MRs unless there are merge conflicts with `master`. GitLab will automatically rebase on top of `master` when batching MRs. |