The life-cycle of merge conflicts: processes, barriers, and strategies

Merge conflicts occur when developers make concurrent changes to the same part of the code. They are an inevitable and disruptive aspect of collaborative software development. Thus tool builders and researchers have focused on the prevention and automatic resolution of merge conflicts. However, there is little empirical knowledge about how developers actually monitor for merge conflicts and plan, perform, and evaluate resolutions. Without such knowledge, tool builders might be building on the wrong assumptions and researchers might miss opportunities for improving the state of the art. We conducted semi-structured interviews with 10 software developers across 7 organizations, including both open-source and commercial projects. We identify key processes, techniques, and perceptions from developers, which we extend and validate via two surveys, a Barriers Survey and a Processes Survey, of 162 and 102 developers, respectively. Among others, we find that developers rely on reactive strategies of monitoring for merge conflicts. We find that developers defer responding to conflicts based on their perception of the complexity of the conflicting code and that deferring affects the workflow of the entire team. Developers also rely on this perception to visually evaluate their merge conflict resolutions for correctness. Finally, developers’ perceptions alter the impact of tools and processes designed to preemptively and efficiently resolve merge conflicts. Understanding their processes and perceptions can help design human-oriented tools that better support their individual development processes.