4 ms·
Ah, that's what a merge train is. I always found the term confusing. We pay for Premium, but we don't use merge trains. We use only fast forward merging, so I g
by usr1106 3y ago
Ah, that's what a merge train is. I always found the term confusing. We pay for Premium, but we don't use merge trains. We use only fast forward merging, so I guess it's a no-op in that case.
- IshKebab 3y agoIt's not a nop. Merge queues solve the following issue: 1. Author 0 makes branch_0 and tests it in CI. It passes. 2. Author 1 makes branch_1 and tests it in CI. It passes. 3. They both merge their branches. This can break `master`, irrespective of the kind of merging you use. Fundamentally two people can make changes that are valid (pass CI) independently but not when combined. That kind of breakage gets more common the more different people you have working on a project. If you just have a handful of people it's relatively rare so you can just accept `master` breaking occasionally. If you have a few dozen people or more then it's pretty much a requirement. I don't think there are any serious downsides to enabling it.
- usr1106 3y agoIf you are limited to fast forward merging only one of your authors can merge. The second one needs to rebase and their updated MR will go through CI again, now on top of the first author's commit that has already been merged.
- mkbosmans 3y agoI think that is unique to Gitlab though. For example Azure DevOps will rebase the branch for you when completing a pull request.
- IshKebab 3y agoAh I see what you mean. Yeah that is roughly equivalent to a manual merge queue. It's going to fall apart on medium/large teams because you'll constantly be rebasing and rerunning CI.