Working in a 19 developers team (and counting) has its perks, but merging isn’t one of them.
Anyone who has worked with a big team on a big project has experienced merge conflicts at least once.
If you have never seen a list of ‘CONFLICT’ lines when rebasing or merging commits, let me give you some insight. Conflicts happen when two people make changes in the same place in the same files. As a result, a developer must solve the conflict by hand, i.e. hand-pick which modifications should be kept. Resolving conflicts is a tedious task but conflicts are more often than not pretty easy to solve.
This problem has bugged me for quite some time now and at first my idea was to write a syntax-aware merge tool. I’m not the first to have had this idea (Ian Clarke talked about it in 2008 and again in 2011) and some commercial, proprietary tools seem to handle this for $7 a month.
But as interesting as it sounds, building a semantic parser and merger is a really huge task so I took another point of view on the problem. Instead of trying to build a complex solver that would understand and solve all kinds of conflicts, I chose to build a lot of small, simple solvers and a basic tool to chain them.
This is how AutoMergeTool was born.
The basic process of the AutoMergeTool can be easily described. Whenever a file reveals one or more conflicts during a merge/rebase, AutoMergeTool will launch one solver after the other until all conflicts are solved.
In cases where the conflits cannot be resolved by any of the solvers, the tool will open a Visual Editor so the conflict can be solved manually:
Once I successfully completed the script, all I had to do was to write the different solvers. For that I had a single rule inspired by the Unix philosophy: “write a solver that does one thing and does it well”. The first solver only dealt with Java import conflicts, which are easy to solve but take a lot of time.
The tool suite now has 7 solvers, most of which can be fine tuned. Out of those, only the first one is specific to Java source files; all the others can be used regardless of your preferred programming language.
AutoMergeTool is also extensible so that you can write your own solvers for the problems you often experience or that may be specific to your file types.
The first time I used it at Deezer, it was for a rebase of a large refactoring, which was around 50 commits behind master. On my first try, there was around sixty conflicts in thirty different files.
After building the first draft of AutoMergeTool and running it, I only had to solve 3 conflicts manually; all the others were solved automatically. Since then we have been dogfooding this tool internally within the Deezer Core Android team and have reduced the time spent on merge conflicts, also improving the mood of the developers performing merges or rebases.
AutoMergeTool is open sourced (under the Apache Licence 2.0) so any issues, feature requests, pull requests or feedback are welcome. I presented the first public version of AutoMergeTool during AndroidMakers 2017. French speakers can watch the presentation below:
