Investigating the merge conflict life-cycle taking the social dimension into account

Abstract

Context. Software development is a collaborative and distributed activity in which success depends on the ability to coordinate social and technical assets. Version control systems help developers to manage technical assets (e.g., code changes) over time by tracking code contributions, especially when involving collaborations of multiple developers. This allows developers to address different programming tasks (e.g., bug fixing and adding new features) simultaneously without losing changes. After fulfilling their tasks, developers can merge their possibly concurrent changes to the main repository to have their work incorporated into the mainstream. A merge scenario includes the whole timeline of creating a project branch, committing changes independently to the project main branch, and creating a merge commit. Problem. In collaborative software development, merge conflicts arise when developers integrate concurrent code changes. Merge conflicts are a notorious problem in collaborative software development. Whereas merge conflicts are common to introduce, they bring several issues to software projects. For instance, merge conflicts: (i) distract developers from their workflow, (ii) negatively impact team productivity, motivation, and keeping the schedule, and (iii) resolving them is a difficult, time-consuming, and often error-prone task. Despite a substantial number of studies investigating merge conflicts, the social dimension of the problem (e.g., the influence of developer communication and developer roles related to conflicts) is often ignored. Goals. In this thesis, we seek out to understand the role the social dimension plays in the merge conflict life cycle. The assumption is that, by deeply understanding the social dimension of the problem, we are able to provide actionable directions for researchers, tool builders, and practitioners to efficiently avoid, predict, and resolve merge conflicts. Method and Results. To reach our goals, we conducted a series of empirical studies investigating the merge conflict life-cycle. As a technical foundation, we created a framework, 4CsNet, to automatically mine and rebuild historical information of open source repositories that follow the three-way merge pattern. 4CsNet retrieves technical information using the Git version control system and social information mainly using GitHub issues and events. With the data collected by 4CsNet, we conducted four empirical studies. In the first empirical study, we investigated the relation between the communication activity and merge conflicts motivated by the popular belief that communication and collaboration successes are mutually dependent. We found that active GitHub communication is not associated with the emergence or avoidance of merge conflicts even though developers communicate with each other. In the second empirical study, we investigated whether it is possible to predict merge conflicts with social measures (i.e., developer roles at coarse- and fine-grained levels). The motivation is that, effectively predicting merge conflicts decreases the cost of constantly pulling and merging a large number of branch combinations (i.e., speculative merging), which makes awareness tools reliable and feasible in practice. Our results show that it is possible to predict merge conflicts taking the social perspective into account with 100% of recall (i.e., all real conflicts are correctly identified). However, to achieve state-of-the-art performance (i.e., combination of recall, prediction, accuracy, AUC), technical measures (e.g., the number of lines of code in conflict or the number of chunks) are necessary. On one hand, our results highlight the importance of investigating the social perspective, especially when developers coordinate themselves without sophisticated tool support. On the other hand, this study highlights that the technical perspective is still essential to predict merge conflicts. In the third empirical study, we investigated developer roles and specific developer code changes. The motivation is that understanding social aspects of conflicting contributors and their activity on changing source files can help managers or developers themselves to decide which developers to instruct to avoid merge conflicts. Our results show that 80% of contributors are involved in one or two merge scenarios, and only 3.8% of developers are involved in more than 10 conflicting scenarios. We also found that 48% of the project's top contributors participated in more than 50% of the conflicting merge scenarios in their project. This is evidence that these developers are related to merge conflicts, and a better coordination of these developers might reduce the number of merge conflicts. In the fourth empirical study, we moved to the end of the merge conflict life-cycle investigating the challenges and factors related to the merge conflict resolution. The premise is that understanding which kind of merge conflicts are time-consuming to resolve, developers should focus on avoiding these kinds of conflicts mostly. Our results show that measures indirectly related to merge conflicts (i.e., measures related to the merge scenario changes) are more strongly correlated with merge conflict resolution time than measures directly related to merge conflicts (i.e., merge conflict characteristics). Aiming at cross-validating our results and searching for new findings, we surveyed 140 developers. We found four main challenges on merge conflict resolution: lack of coordination, lack of tool support, flaws in the system architecture, and lack of testing suite or pipeline for continuous integration. Conclusion. In this thesis, we call the attention of researchers, tool builders, and practitioners to the importance of including the social dimension when investigating merge conflicts. Our findings also provide evidence that they should also look at the technical dimension more closely. We present below the main contributions of our thesis. GitHub communication activity itself does not influence the occurrence or avoidance of merge conflicts. It is possible to correctly predict all real merge conflicts using only social measures (e.g., the number of top or occasional contributors touching the source branch). The top conflicting contributor of a project is often related to the majority of merge conflicts of a project, which is evidence that properly coordinating this developer reduces the number of merge conflicts of a project. The branch that developers are touching is an important factor when investigating merge conflicts. For instance, changes in the source branch are 3 times more conflict-prone than changes in the target branch when occasional contributors are involved in the code changes. Hence, branches in the source branch should be more closely monitored. Changes indirectly related to merge conflicts (e.g., the number of chunks changed in the merge scenario) have a greater impact on the merge conflict resolution time than changes directly related to merge conflicts (e.g., the number of chunks in conflict). Hence, researchers should consider changes indirectly related to merge conflicts to predict and avoid the merge conflicts, for instance. We identified four main challenges on merge conflict resolution reported by software developers (lack of coordination, lack of tool support, flaws in the system architecture, and lack of testing suite or pipeline for continuous integration) and purpose a set of solutions/guidelines to support developers to get around these challenges, minimise the emergence of merge conflicts, and make conflict resolutions faster.

Kontext. Softwareentwicklung ist eine kollaborative und verteilte Aktivität, bei der der Erfolg von der Fähigkeit abhängt, soziale und technische Ressourcen zu koordinieren. Versionskontrollsysteme helfen Entwicklern, technische Assets (z. B. Codeänderungen) im Laufe der Zeit zu verwalten, indem sie Codebeiträge verfolgen, insbesondere wenn mehrere Entwickler zusammenarbeiten. Dadurch können Entwickler verschiedene Programmieraufgaben (z.B., Fehlerbehebung und Hinzufügen neuer Funktionen) gleichzeitig bearbeiten, ohne dass Änderungen verloren gehen. Nach Erfüllung ihrer Aufgaben, können Entwickler ihre möglicherweise gleichzeitigen Änderungen im Haupt-Repository zusammenführen, um ihre Arbeit in den Mainstream zu integrieren. Ein Zusammenführungsszenario umfasst die gesamte Zeitleiste der Erstellung eines Projektz branch, der unabhängigen Übertragung von Änderungen an den Haupt Branch des Projekts und der Erstellung eines Merge-Commits. Problem. Bei der kollaborativen Softwareentwicklung entstehen Merge Konflikte, wenn Entwickler gleichzeitige Codeänderungen integrieren. Merge Konflikte sind ein bekanntes Problem bei der kollaborativen Softwareentwicklung. Während Merge Konflikte häufig auftreten, bringen sie bei Softwareprojekten mehrere Probleme. Merge Konflikte zum Beispiel: (i) lenken Entwickler von ihrem Arbeitsablauf ab, (ii) wirken sich negativ auf die Teamproduktivität, Motivation und Einhaltung des Zeitplans aus und (iii) sie zu lösen ist ein schwieriger, zeitaufwändiger und oft ein Fehler -anfällige Aufgabe. Trotz einer beträchtlichen Anzahl von Studien, die Merge-Konflikte untersuchen, wird die soziale Dimension des Problems (z.B., der Einfluss der Entwicklerkommunikation und der Entwicklerrollen im Zusammenhang mit Konflikten) häufig ignoriert. Ziele. In dieser Arbeit versuchen wir zu verstehen, welche Rolle die soziale Dimension im Lebenszyklus von Merge Konflikte spielt. Wir gehen davon aus, dass wir durch ein tiefes Verständnis der sozialen Dimension des Problems in der Lage sind, Forschern, Werkzeugbauern und Praktikern umsetzbare Anweisungen zu geben, um Merge Konflikte effizient zu vermeiden, vorherzusagen und zu lösen. Methode und Ergebnisse. Um unsere Ziele zu erreichen, haben wir eine Reihe empirischer Studien durchgeführt, die den Lebenszyklus von Merge Konflikte untersuchten. Als technische Grundlage haben wir ein Framework, 4CsNet, erstellt, um historische Informationen von Open-Source-Repositories, die dem Drei-Wege-Merge-Muster folgen, automatisch zu extrahieren und neu zu erstellen. 4CsNet ruft technische Informationen mithilfe des Versionskontrollsystems Git und soziale Informationen hauptsächlich mithilfe von GitHub-Problemen und -Ereignissen ab. Mit den von 4CsNet gesammelten Daten führten wir vier empirische Studien durch. In der ersten empirischen Studie untersuchten wir den Zusammenhang zwischen der Kommunikationsaktivität und Merge Konflikte, die durch die weit verbreitete Überzeugung motiviert sind, dass Kommunikations- und Kollaborationserfolge einander bedingen. Wir stellten fest, dass eine aktive GitHub-Kommunikation nicht mit der Entstehung oder Vermeidung von Merge-Konflikten verbunden ist, obwohl Entwickler miteinander kommunizieren. In der zweiten empirischen Studie untersuchten wir, ob es möglich ist, Merge Konflikte mit sozialen Maßnahmen (d. h. Entwicklerrollen auf grob- und feinkörniger Ebene) vorherzusagen. Die Motivation besteht darin, dass durch eine effektive Vorhersage von Merge Konflikte die Kosten für das ständige Ziehen und Zusammenführen einer großen Anzahl von Zweigkombinationen (d. h. spekulatives Zusammenführen) gesenkt werden, was Awareness-Tools zuverlässig und in der Praxis umsetzbar macht. Unsere Ergebnisse zeigen, dass es möglich ist, Merge Konflikte unter Berücksichtigung der sozialen Perspektive mit 100% Rückruf vorherzusagen (d. h. alle realen Konflikte werden korrekt identifiziert). Um jedoch eine Leistung auf dem neuesten Stand der Technik (d.h., Kombination aus Rückruf, Vorhersage, Genauigkeit, AUC) zu erreichen, sind technische Maßnahmen (z. B. die Anzahl der in Konflikt stehenden Codezeilen oder die Anzahl der Chunks) notwendig. Einerseits unterstreichen unsere Ergebnisse, wie wichtig es ist, die soziale Perspektive zu untersuchen, insbesondere wenn Entwickler sich ohne ausgefeilte Toolunterstützung koordinieren. Andererseits unterstreicht diese Studie, dass die technische Perspektive immer noch von entscheidender Bedeutung ist, um Merge Konflikte vorherzusagen. In der dritten empirischen Studie untersuchten wir Entwicklerrollen und spezifische Änderungen am Entwicklercode. Die Motivation besteht darin, dass das Verständnis der sozialen Aspekte widersprüchlicher Mitwirkender und ihrer Aktivitäten beim Ändern von Quelldateien Managern oder Entwicklern dabei helfen kann, selbst zu entscheiden, welche Entwickler sie anweisen sollten, um Merge Konflikte zu vermeiden. Unsere Ergebnisse zeigen, dass 80% der Mitwirkenden an einem oder zwei Zusammenführungsszenarien beteiligt sind und nur 3,8% der Entwickler an mehr als 10 widersprüchlichen Szenarien beteiligt sind. Wir haben außerdem herausgefunden, dass 48% der Top-Mitwirkenden des Projekts an mehr als 50% der widersprüchlichen Zusammenführungsszenarien in ihrem Projekt beteiligt waren. Dies ist ein Beweis dafür, dass diese Entwickler mit Merge Konflikte in Zusammenhang stehen, und eine bessere Koordination dieser Entwickler könnte die Anzahl der Merge Konflikte verringern. In der vierten empirischen Studie näherten wir uns dem Ende des Lebenszyklus des Merge-Conflites und untersuchten die Herausforderungen und Faktoren im Zusammenhang mit der Lösung des Merge-Konfliktes. Die Prämisse ist, dass Entwickler sich darauf konzentrieren sollten, diese Art von Konflikten weitgehend zu vermeiden, wenn sie verstehen, welche Art von Merge Konflikte zeitaufwändig zu lösen sind. Unsere Ergebnisse zeigen, dass Maßnahmen, die sich indirekt auf Merge Konflikte beziehen (d.h., Maßnahmen im Zusammenhang mit Änderungen des Zusammenführungsszenarios), stärker mit der Lösungszeit für Merge Konflikte korrelieren als Maßnahmen, die direkt mit Merge Konflikte in Zusammenhang stehen (d.h., Merkmale von Merge Cinflicts). Um unsere Ergebnisse gegenseitig zu validieren und nach neuen Erkenntnissen zu suchen, befragten wir 140 Entwickler. Wir stellten vier Hauptherausforderungen bei der Lösung von Zusammenführungskonflikten fest: Mangel an Koordination, Mangel an Tool-Unterstützung, Mängel in der Systemarchitektur und Mangel an Testsuite oder Pipeline für kontinuierliche Integration. Schlussfolgerung. In dieser Arbeit machen wir Forscher, Werkzeugbauer und Praktiker darauf aufmerksam, wie wichtig es ist, die soziale Dimension bei der Untersuchung von Merge Konflikte einzubeziehen. Unsere Erkenntnisse belegen zudem, dass auch die technische Dimension stärker in den Blick genommen werden sollte. Im Folgenden stellen wir die Hauptbeiträge unserer Dissertation vor. • Die GitHub-Kommunikationsaktivität selbst hat keinen Einfluss auf das Auftreten oder die Vermeidung von Merge Konflikte. • Es ist möglich, alle echten Merge Konflikte korrekt vorherzusagen, indem man nur soziale Kennzahlen verwendet (z. B. die Anzahl der Top- oder gelegentlichen Mitwirkenden, die den Quellzweig berühren). • Der Mitwirkende mit den größten Konflikten in einem Projekt steht häufig im Zusammenhang mit den meisten Merge Konflikte eines Projekts. Dies ist ein Beweis dafür, dass die richtige Koordination dieses Entwicklers die Anzahl der Merge Konflikte eines Projekts verringert. • Der Branch, den Entwickler berühren, ist ein wichtiger Faktor bei der Untersuchung von Merge Konflikte. Beispielsweise sind Änderungen im Source-Branch dreimal konfliktanfälliger als Änderungen im Target-Branch, wenn gelegentliche Mitwirkende an den Codeänderungen beteiligt sind. Daher sollten Branches im Source-Branch genauer überwacht werden. • Änderungen, die indirekt mit Merge Konflikte zusammenhängen (z.B., die Anzahl der im Zusammenführungsszenario geänderten Blöcke), haben einen größeren Einfluss auf die Auflösungszeit der Merge-Konflikte als Änderungen, die direkt mit Merge Konflikte zusammenhängen (z.B., die Anzahl der im Konflikt befindlichen). Daher sollten Forscher Änderungen berücksichtigen, die indirekt mit Merge Konflikte zusammenhängen, um beispielsweise Merge Konflikte vorherzusagen und zu vermeiden. • Wir identifizierten vier Hauptherausforderungen bei der Lösung von Merge Konflikte, die von Softwareentwicklern gemeldet wurden (mangelnde Koordination, mangelnde Toolunterstützung, Mängel in der Systemarchitektur und fehlende Testsuite bzw Pipeline für kontinuierliche Integration) und wir entwickelten eine Reihe von Lösungen/Richtlinien, um Entwickler dabei zu unterstützen, diese Herausforderungen zu meistern, das Auftreten von Merge Konflikte zu minimieren und Konfliktlösungen schneller zu gestalten.