One of the most annoying tasks for a developer is to fix git conflicts. You open a pull request, ace the code review process, all checks are passing, and when you go for that merge button you find out that it is blocked because of git conflicts. Wouldn’t it be nice if you could avoid this situation?

Developers that use a git flow branching model rely on 3-way merge tools (like git-merge or kdiff3) to automatically merge their changes.

Unfortunately, these tools are unable to resolve all concurrent changes made to files in the branches involved in the merge. As developers, we experience these unresolved concurrent changes as git merge conflicts. As the name suggests, the existence of a git merge conflict prevents the merge action.

The exact definition of a git merge conflict depends on the algorithm used to compute the merge commit. The most widely used algorithms are textual in nature – a conflict in a file means that the branches involved in the merge have both made modifications to the same line in a file. Nowadays, there are much more sophisticated algorithms to compute merge commits than what is offered in GitHub, Gitlab, or Bitbucket. For an overview check out the article Verified Three-Way Program Merge – we do plan to incorporate some of them soon into Reviewpad.

However, a merge is and always will be a sensitive operation. That is, some concurrent changes really do conflict and require human intervention.

The reality is that git merge conflicts are relatively common in highly collaborative teams.

While some conflicts are unavoidable, it is possible to create awareness of their future existence so that you can mitigate their effects.

Reviewpad’s Concurrent Pull Request Analysis

At Reviewpad, we believe that git conflicts are being discovered at a very late stage in the review process. That is very annoying because sometimes after you have gone through the entire review process you find out that a recently merged PR just introduced git conflicts. Now, you need to restart the entire process.

So, to reduce this effort we have built into Reviewpad a concurrent pull request analysis that provides information about future git conflicts.

The way Reviewpad keeps track of potential future git conflicts is by checking if modified files in a particular pull request are also modified in other open pull requests that share the base branch.

We have been using this check in two use cases that improve the review process.

Improve reviewer selection

Finding the right reviewer can be difficult at times in highly collaborative projects. Who better to review than a developer who is also changing the same parts of the code, or a reviewer of such PR?

In the video, we can see that there is another open PR that is also changing the ci.yml. The author of that pull request could be a great candidate to review this pull request. Ideally, both developers could collaborate so that all conflicts could be avoided once one of the PRs is merged.

Improve merge strategy

As we mentioned in the beginning of this article, there is nothing more annoying than a pull request that is ready to merge but will be blocked by the merge of another PR. Although we can’t completely avoid this situation, we have integrated this check into Reviewpad’s Release Board so that it becomes evident.

In this first version, we have decided to restrict this information to pull requests that are ready to merge. Here’s what a PR card with conflicts in concurrent PRs looks like:

In the following video, we go over the simple flow of approving a PR, seeing the conflicts in the Ready to Merge column and also the effect of merging this PR which moves the conflicting PR back to the Git conflicts column.

Cool. How do I check this out by myself?

We have a public beta version of Reviewpad available at reviewpad.com/get-started. You will need to create a new account and once you log in for the first time, you will see the following page to connect to a code host:

You can connect to GitHub through our OAuth app or manually add a personal access token. The OAuth requires minimal scopes to be able to read and comment on public repositories.

And voilà – you are ready to get started with Reviewpad!

We are just getting started with incorporating features that improve the merge experience in pull requests. Feel free to reach us on our community Slack with requests!