Comparing the different Merge Request / Pull Request merge methods in GitLab and GitHub
Although I've been a big fan of GitLab for years, unfortunately every company I've worked for has been centred around GitHub.com or GitHub Enterprise Server (self-hosted).
This means that I've gotten rather used to the way that GitHub does merges, opposed to GitLab.
When I recently rolled out go-semantic-release on dependency-management-data (DMD) to manage releasing the project based on Conventional Commits, I wanted to replace the default merge commits with what GitHub calls the "rebase merge".
(Aside: I didn't investigate using go-semantic-release with a merge commit + conventional commits)
When looking at GitLab's options in the Merge Requests settings page, I wasn't sure which of these would do what I would expect of GitHub:
So that's what this post is - me explaining the differences based on GitHub's documentation and GitLab's documentation.
Merge commit
GitLab's Merge commit method aligns with how GitHub's merge method works, introducing a merge commit between the two branches.
GitLab's Merge commit method also fulfills GitHub's "squash merge" functionality, allowing the author/merger to squash their commits at that point.
However, GitLab provides much more flexibility around squashing, via their settings page:
Merge commit with semi-linear history
This appears to be similar to GitHub's Merge commit method, with the Require branches to be up to date before merging setting enabled, but as its own configuration.
Also, unlike GitHub, when a Merge Request is behind the target branch, it can be rebased:
This gives you the ability to update the branch that the Merge Request is from, straight from the UI, instead of requiring that you check out the code locally and make the same changes. It's a small quality-of-life improvement, but appreciated!
Fast-forward merge
GitLab's Merge commit method aligns with how GitHub's "rebase merge" method, taking each commit from the source branch and rebasing it onto the target branch.
