# Automatic Detection and Resolution of Software Merge Conflicts: Are We There Yet?

**Authors:** Bowen Shen, Cihan Xiao, Na Meng, Fei He  
**arXiv:** [2102.11307](https://arxiv.org/abs/2102.11307)  
**Date:** 2021-02-22  
**Summary page:** https://www.summarizepaper.com/en/arxiv-id/2102.11307v2/

## Key points

- Developers create different branches for adding new features or fixing bugs, and merge them periodically to release software with new updates.
- Merging can lead to conflicts when textual edits from different branches overlap or when the co-application of those edits leads to compilation or runtime errors.
- A hybrid approach that combines automatic detection with manual inspection was taken in this study to address fundamental research questions about how conflicts are introduced, how developers manually resolve them, and what conflicts cannot be handled by current tools.
- The analysis revealed three phenomena: compiling and dynamic conflicts are harder to detect than textual conflicts; developers usually resolved similar textual conflicts with similar strategies; developers manually fixed most of the inspected compiling and dynamic conflicts by similarly editing the merged version as what they did for one of the branches.
- Same-typed textual conflicts in the same commits were usually resolved with similar strategies, making it feasible to predict developers' strategy for any arbitrary textual conflict given the resolution of other textual conflicts in the same merging commit.
- Text-based merges can produce higher-order conflicts by silently integrating semantically conflicting edits while compilation and testing fail to capture these produced conflicts. Better tools are needed to detect all kinds of conflict altogether instead of detecting certain ones at the cost of introducing others.
- Developers usually resolved higher-order conflicts by consistently applying similar edits to similar code locations. By automating such practices, future tools can resolve many higher-order conflicts observed in this study.
- Existing tools cannot detect or resolve many types of merge conflict issues effectively; for example 79% of compiling conflicts and 75% of dynamic ones were not reported or reflected by any explored automatic approach let alone resolved automatically.
- The study sheds light on challenges and opportunities for automatic detection and resolution of merge conflicts in software development; it also highlights related areas like systematic program editing and change recommendation systems which can help design better human-in-the-loop approaches. Future work will involve building semi-automatic tools based on insights gained from this study.

## Summary

In software development, developers create different branches for adding new features or fixing bugs, and periodically merge them to release the software with new updates. However, merging can lead to conflicts when textual edits from different branches overlap or when the co-application of those edits leads to compilation or runtime errors. While previous studies have examined the popularity of merge conflicts and how they are related to code smells or software development processes, some fundamental research questions remain unexplored. These include how conflicts are introduced, how developers manually resolve them, and what conflicts cannot be handled by current tools. To address these questions, a hybrid approach that combines automatic detection with manual inspection was taken in this study. The researchers analyzed 204 merge conflicts and their resolutions in 15 open-source repositories using this approach. The analysis revealed three phenomena: firstly, compiling and dynamic conflicts are harder to detect than textual conflicts; secondly, developers usually resolved similar textual conflicts with similar strategies; thirdly, developers manually fixed most of the inspected compiling and dynamic conflicts by similarly editing the merged version as what they did for one of the branches. The study provides multiple insights into software merge conflicts and their resolutions. For instance, same-typed textual conflicts in the same commits were usually resolved with similar strategies. This means that predicting developers' strategy for any arbitrary textual conflict is feasible given the resolution of other textual conflicts in the same merging commit. Additionally, text-based merges can produce higher-order conflicts by silently integrating semantically conflicting edits while compilation and testing fail to capture these produced conflicts. Therefore better tools are needed to detect all kinds of conflict altogether instead of detecting certain ones at the cost of introducing others. The study also found that developers usually resolved higher-order conflicts by consistently applying similar edits to similar code locations. By automating such practices, future tools can resolve many higher-order conflicts observed in this study. Furthermore, it was discovered that existing tools cannot detect or resolve many types of merge conflict issues effectively; for example 79% of compiling conflicts and 75% of dynamic ones were not reported or reflected by any explored automatic approach let alone resolved automatically. Overall, the study sheds light on the challenges and opportunities for automatic detection and resolution of merge conflicts in software development; it also highlights related areas like systematic program editing and change recommendation systems which can help in designing better human-in-the-loop approaches to focus developers' manual effort on the most important and challenging conflict scenarios. Future work will involve building semi-automatic tools based on insights gained from this study.