3 ms·
Our current policy in GitLab is like a combination of 1 and 2: > Merge commit with semi-linear history > A merge commit is created for every merge, but mergin
by umvi 8y ago
Our current policy in GitLab is like a combination of 1 and 2:
> Merge commit with semi-linear history
> A merge commit is created for every merge, but merging is only allowed if fast-forward merge is possible. This way you could make sure that if this merge request would build, after merging to target branch it would also build.
- deleted 8y ago[deleted]
- dbaupp 8y agoA more general approach to this is something like https://bors.tech/ https://bors.tech/ where each merge is explicitly tested before hitting the main branch. Branches then don't need to be manually rebased, but there's still much reduced risk of failures due to not merging (if tests aren't even run on the potential merge commit), or "merge skew" (if they are, but not every time the target branch is updated, like Travis CI, etc., do by default).
- deepsun 8y agoExactly, we prefer that too. But we haven't found a way to enforce that on GitHub. Is there builtin precommit hooks for that on Gitlab?
- umvi 8y agoNot sure about GitHub. In GitLab it's just a Merge Request setting[1]. [1] https://docs.gitlab.com/ee/user/project/merge_requests/#semi-linear-history-merge-requests https://docs.gitlab.com/ee/user/project/merge_requests/#semi...