New Rebase Method with Strict Mode!

I know that title might sound a little bit obscure for developers that do not leverage Mergify. For our users however, it’s fantastic news!

A few weeks ago, we’ve added a new configuration option to Mergify’s strict merge mode. If you don’t know what this strict merge mode is, in summary, it makes sure that your pull requests are merged serially and with their code rebased on top of each other. This avoids merging pull requests that are out-of-date and that can break each others.

If you want to read more about strict merge mode, you can check it out in our documentation. It explains what the problem is if you don’t use strict mode, and why you really, really should be using Mergify.

The new option we introduced is named strict_method and is documented in the merge action. It takes the method that should be used to update the pull request, either merge (the default) or the new rebase method.

What Is This New Option About?

Up until now, the only way for the strict mode to update a pull request was by merging the target branch into the pull request. That works fine, but it’s a trade-off compared to the alternative which is rebasing. Why?

Each time the pull request is a candidate to be merged, Mergify merges the target branch inside the pull request to be sure the pull request is up-to-date. This creates a merge commit that you can see in the pull request timeline:

When the pull request gets finally merged into the target branch, those merge commits are still present in the Git history. That’s not a problem per-say, but it can make the Git history harder to read.

What if, instead of merging the target branch into the pull request, Mergify would rebase the pull request on top of the target branch? That’s now possible!

In that case, you will not see any new (merge) commit in the pull request timeline, avoiding the creation of merge commits. Mergify will run git rebase and then force-push the result of that rebase to GitHub. Here you go, a freshly rebased pull request ready to be merged.

However, rebasing a branch might fail more often than merging it. When using git merge, Git does a three-way merge, which is more capable of resolving conflicts that wouldgit rebase.

In summary, choosing between merge and rebase is a trade-off that can be summarized like that:

Merge

Pros: More likely to resolve conflicts
Cons: Having merge commits in the git history

Rebase

Pros: No added commits in the git history
Cons: Less likely to resolve conflicts

I hope that’ll make it clearer and easier to pick your strict_method.