Mergify case study
5 min read
Git and GitHub
Unless you are new to the entire developer or open source ecosystem, you've probably heard about Git and GitHub, and you may have even used them a lot. Nearly every organization uses git in some way, whether working with closed source, or open source projects.
Git is a very useful tool that helps you collaborate with other people easily, and makes it possible for multiple people to work on the same project at the same time. Check this video to learn more about Git and GitHub.
The merge conflict problem
Having merge conflicts is a pretty common issue, especially when many folks are working on inter-related code. For example, two people might be adding a few entries to a registry.
What exactly causes a merge conflict?
Good question. Let's use the above example of registries. Let's say that devA and devB are adding to the registry. Now devA has added about 50 unique entries to the registry and has opened a PR(Pull Request). At the same time, devB also added around 15 entries to the registry, and 8 of them are the same as devA.
This will lead to a merge conflict. Since two developers are working on the same file, some of the code overlaps, and hence it creates a merge conflict.
Now to remove these merge conflicts, devB will have to manually go through the conflicts, and decide which commits to keep, and which to discard. This is quite a time-consuming and difficult task.
Stale Pull Requests
Stale PRs on the other hand, happen because the maintainers did not merge the PRs because of some reason. Either there was a different PR that solved the problem, or the maintainers were waiting for a different PR to get merged before your PR, etc.
Whatever the reason, the PRs have had no activity in a long time and hence, are marked as stale. Keeping stale PRs is not a good idea, since it can have other PRs to get merge conflicts, and a new contributor will have no idea what to do.
Mergify to the rescue
Mergify is a tool that can help you automate a lot of tasks including automatically merging PRs, fixing merge conflicts, assigning maintainers to review PRs, and much more.
Automatically Merge PRs
When you read the automatically merging PRs I'm sure you thought this would be a bad idea. Of course, if you directly merged a PR without running any tests, it is a very bad idea. But you can define custom rules and tell mergify, to merge the PR only after all the checks are successful.
Fix merge conflicts
Mergify also fixes the issue of merge conflicts by using a merge queue. What this does is, it merges the PR sequentially. Taking an example for this, let's say that a PR was created at 8 am, and another one at 10 am. All checks have passed for both the PRs. Now mergify will first merge the PR at 8 am, then the checks for the PR at 10 am will run again. If the checks pass, then they will automatically get merged.
You can also prioritize your PRs so the important PRs will get merged first. GitHub has a limited time for GitHub actions, i.e you pay for a set number of run minutes. Rather than overconsuming your CI time by trying to merge multiple pull requests, mergify runs the checks only once before the pull request gets merged.
Automatically Update Branches
When you contribute to a project, you have to fork a project to open a PR with your changes. Oftentimes, a PR will be active for a few weeks, which means that other PRs will be getting merged, and the code base will keep getting updated. Usually, contributors have to manually update their branches, and fix and merge conflicts that may arise with this.
Mergify will automate this update process so that the contributors no longer need to manually click on the update-branch button.
Assign Reviewers
If you have a large codebase that uses multiple frameworks and technologies, you have multiple maintainers who are experienced in one of those technologies. Let's say a PR was opened that changes a Python file. Normally, a maintainer would see what files were changed and manually assign the correct maintainer to review.
Mergify detects what files were changed and automatically assigns the maintainer who should review the PR.
How does it work
We talked a lot about how mergify makes it easier to automate the GitHub workflow, fix merge conflicts, etc. But how do you set this up?
It's very simple. You can use mergify as a GitHub Action and define some rules that will be followed.
Here is a practical example on how you can define mergify rules and run them. If you want a more in-depth look into how to define the rules, you can check out the documentation.
What's unique about Mergify
By now you have a good idea about why mergify is such a useful tool.
- It allows you to quickly and safely merge PRs without breaking the codebase
- It automates a lot of manual tasks, which helps contributors and maintainers be more productive.
- Automatically rebase code, and fixes merge conflicts
- It is easy to use and allows you to define custom rules.
- Can be used alongside any CI tools such as Jenkins.
Conclusion
While most of these tasks can be done manually, automating them using mergify can save a lot of time and energy, especially in large codebases.
Setting up automation rules can also help in reducing any human errors, and hence reduces the need to revert any commits.