Comparing the different Merge Request / Pull Request merge methods in GitLab and GitHub

Featured image for sharing metadata for article

Although I've been a big fan of GitLab for years, unfortunately every company I've worked for has been centred around 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:

A settings widget with three options for merging - "Merge commit" (checked), "Merge commit with semi-linear history" and "Fast-forward merge"

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:

A settings widget with four options under the "Squash commits when merging" setting - "Do not allow", "Allow" (checked), "Encourage", and "Require"

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:

The Merge Request UI in GitLab showign that the merge is blocked because "the source branch must be rebased onto the target branch", and giving the user an option to "Rebase", or less emphasised, "Rebase without pipeline"

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.

Written by Jamie Tanna's profile image Jamie Tanna on , and last updated on .

Content for this article is shared under the terms of the Creative Commons Attribution Non Commercial Share Alike 4.0 International, and code is shared under the Apache License 2.0.

#blogumentation #gitlab #github.

This post was filed under articles.

Interactions with this post

Interactions with this post

Below you can find the interactions that this page has had using WebMention.

Have you written a response to this post? Let me know the URL:

Do you not have a website set up with WebMention capabilities? You can use Comment Parade.