We have 2 gitlab branches that build environments:
- develop (default)
- master
We will merge develop into master for a new production build, and a pipeline is started and builds are executed (branch name is used to get the right CI/CD variables during pipeline jobs).
In gitlab, there are 3 options for merges.
-
Merge commit – Every merge creates a merge commit.
-
Merge commit with semi-linear history – Every merge creates a merge commit. Merging is only allowed when the source branch is up-to-date with its target. When semi-linear merge is not possible, the user is given the option to rebase.
-
Fast-forward merge – No merge commits are created. Fast-forward merges only. When there is a merge conflict, the user is given the option to rebase. If merge trains are enabled, merging is only possible if the branch can be rebased without conflicts.
If we do a merge commit, the following happens:
- we merge develop into master
- master creates a new merge commit, which develop does not have.
- When we next merge develop into master, this new commit confuses develop and causes a messy conflict.
If we do a fast-forward merge, then:
- we are given the option to rebase master with develop, because it is out of touch. We may be confused in this area, but if we are merging develop, this option doesn’t make much sense either.
How should we setup to streamline this approach? What can I do to prevent the merge conflicts?