On the Nature of Merge Conflicts: A Study of 2,731 Open Source Java Projects Hosted by GitHub

Abstract

When multiple developers change a software system in parallel, these concurrent changes need to be merged to all appear in the software being developed. Numerous merge techniques have been proposed to support this task, but none of them can fully automate the merge process. Indeed, it has been reported that as much as 10% to 20% of all merge attempts result in a merge conflict, meaning that a developer has to manually complete the merge. To date, we have little insight into the nature of these merge conflicts. What do they look like, in detail? How do developers resolve them? Do any patterns exist that might suggest new merge techniques that could reduce the manual effort? This paper contributes an in-depth study of the merge conflicts found in the histories of 2,731 open source Java projects. Seeded by the manual analysis of the histories of five projects, our automated analysis of all 2,731 projects: (1) characterizes the merge conflicts in terms of number of chunks, size, and programming language constructs involved, (2) classifies the manual resolution strategies that developers use to address these merge conflicts, and (3) analyzes the relationships between various characteristics of the merge conflicts and the chosen resolution strategies. Our results give rise to three primary recommendations for future merge techniques, that -when implemented -could on one hand help in automatically resolving certain types of conflicts and on the other hand provide the developer with tool-based assistance to more easily resolve other types of conflicts that cannot be automatically resolved.

Can Program Synthesis be Used to Learn Merge Conflict Resolutions? An Empirical Analysis

“…Textual merge conflicts occur when changes from independent commits over a common base cannot be resolved by a textual 3-way differencing tool present in version control systems such as git. Merge conflicts are frequent and annoying, and studies have shown they can have a significant impact on the development lifecycle of projects [1]. Prior works have focused on predicting merge conflicts [2]- [7], resolving them through using structured abstract syntax tree (AST) aware techniques [8]- [12], or even verifying semantic correctness of merges using program verifiers [13].…”

“…Instead of devising an algorithm to resolve any merge conflict, we pose the merge conflict resolution problem as that of learning repetitive resolution patterns from the history of a given project. In fact, Ghitto et al [1] observed patterns are commonplace in conflict resolution for a large project when viewed over the history of a project. They also postulate that learning common resolution patterns in a project can be a useful aid for developers in resolving future conflicts.…”

Predicting Merge Conflicts in Collaborative Software Development

“…While semi-structured merge is faster than structured merge and more precise than unstructured merge, it is still not used in software industry due to the effort that is needed in order to support new programming languages. A recent large-scale empirical study by Ghiotto et al [28] also investigated various characteristics of textual merge conflicts, such as their size and resolution types. The results suggests that since merge conflicts vary greatly in terms of their complexity and resolutions, having an automatic tool that can resolve all types of conflicts is likely not feasible.…”

UML2Merge: a UML extension for model merging

“…override, merge and union described in [20]). The matching and merging strategies were chosen because they have been applied to a wide range of merging scenarios [5] -evolution of design models, ontology merging, and conceptual model merge. Furthermore, they have been recognised as handy, helpful heuristics in evolving architectural models (e.g.…”

“…At some point, it is necessary to combine these models to produce a 'big picture' view of the overall architecture. For this reason, a significant body of research has been done in the field of collaborative software modelling [4], merge conflicts [5], model synchronisation [6], integration of heterogeneous models [7], and integration of feature models [8].…”