Why You Should Not Fear Automated Merging

Mergify is soon going to celebrate its first anniversary. During that first year, we had tons of conversation with users. We received a lot of feedback from our users, which helped us to design our solution.

As you know, one of the core features of Mergify is to provide automatic pull request merging based on rules. That means that a bot will push the green merge button instead of a human. And that seemed to trigger hostile reactions from some developers we talked with. They would freak out at the idea of having a software merging their code.

Why?

Well, most of them were having a hard time to explain why they would be scared of doing that. The change and the feeling of losing control probably panicked them. We think it’s irrational: let’s dig into a few of the points they tried to raise here.

Automatic Merge Can Break Things

Sure, merging code can break things. If your system is deployed in production just after being merged, it can be pretty scary to feel that you have no control over when the code is merged.

Some developers think that they have better control over their code and what goes into production if they manually merge the code. They can then go and check everything went fine.

This is crazy.

It’s a waste of time and completely error-prone. There’s no guarantee that you will do the same check every time you click on that merge button. There’s no guarantee you’ll even do the right tests. What if you forget some checks? What if you’re not there to fix the problem?

You have to automate that. The truth is, it’s the first thing to do before enabling automatic merging — I’ll give you that. There’s no point in merging code automatically if your tests don’t run automatically in the first place — or if you don’t have tests (sigh).

But don’t say “a bot can break things.” Say “I need to fix my continuous integration system to make sure anything that is merged is trusted.”

It Could Merge The Wrong Things by Mistake

Really?

I mean, ok, maybe. For the sake of the exercise, let’s say it’s possible. Maybe you wrongly defined your rules. Perhaps there is a nasty bug somewhere that we missed, an obscure corner case. Though in all cases, it’d be fixed promptly not to happen twice and you can just use git revert to get back to the previous state.

Don’t you think it’s more likely that a human would make the same mistake more than once? Think twice!

We Don’t Trust A Bot

I get that. We’ve all seen the movies.

The good news is that Mergify is open source. That means you’ll be able to dive into the source code of our engine (the bot!) if you want. You’ll be able to understand how it works, what it does, and why it does it. It’s possible to understand every part of it.

Better than that, you can also propose bug fixes or implement your own feature! All the development process is done in the open, meaning you can help us build and improve the bot — no secret sauce.

We Don’t Have A Merge Policy

This is something we heard a lot with tiny projects — the ones where you can count the developers on the fingers of one hand. Larger projects tend to have thought about this at some point and have no problem describing the policy they apply to get code merged.

Those small teams might not have a strict policy with rules written into marble. However, if you ask how they decide to merge pull requests, you’ll usually have enough to describe a merge policy. It tends to be simple, but enough to be implemented using Mergify.

Smoother Development Process

In the end, every user we talked with is happy with having a smoother development process. Mergify removes a lot of the friction that can happen with the merge of pull requests, and they would never come back to the old way of merging code.

So, what’s blocking you to enable automatic merging? 😁