Towards requirements for merge conflict avoidance strategies

• Ano de defesa: 2020
• Autor(a) principal: DIAS, Klissiomara Lopes
• Orientador(a): BORBA, Paulo Henrique Monteiro
• Tipo de documento: Tese
• Tipo de acesso: Acesso aberto
• Idioma: por
• Instituição de defesa: Universidade Federal de Pernambuco
• Programa de Pós-Graduação: Programa de Pos Graduacao em Ciencia da Computacao
• País: Brasil
• Palavras-chave em Português: Engenharia de software; Desenvolvimento colaborativo
• Link de acesso: https://repositorio.ufpe.br/handle/123456789/37664

Merge conflicts often occur when developers change the same code artifacts. Such conflicts might be frequent in practice, and resolving them might be costly and is an errorprone activity. To minimize these problems by reducing merge conflicts, it is important to better understand how merge conflicts are affected by technical and organizational factors, so we can derive a set of factors development teams need to pay attention to avoid conflicts. With that aim, we conducted two empirical studies. First, we quantitatively investigate seven factors related to modularity, size, and timing of developers’ contributions by reproducing and analyzing 73504 merge scenarios in GitHub repositories of Ruby and Python MVC projects. Then, to qualitatively evaluate our findings and explore other ways to avoid merge conflicts, we conducted 16 exploratory semi-structured interviews with practitioners across 13 companies, among them 4 global companies. Additionally, we also investigate how developers could be assisted in conflict avoidance by exploring the usefulness of a hypothetical tool for alerting merge conflict risk based on the factors we investigate. We bring quantitative evidence of 6 out of 7 modularity, size, and timing factors that are more likely associated with merge conflicts. We found most interviewees perceive an association between merge conflict occurrence and each factor we investigate in the previous study. Overall, we new 15 merge conflict factors considered important by the interviewees and 11 practices they use to avoid conflicts. Additionally, interviewees say that most merge conflicts are straightforward; exceptions, to mention a few, involve conflicts caused by global refactorings, when changes are related in non-trivial ways, demanding semantic understanding of the changes, and depending on the project phase. Finally, most interviewees consider a tool for alerting merge conflict risk useful for distinct purposes (e.g., to help the integrator or DevOps to early monitoring conflict issues ) and give us insight into contexts in which this type of tool would not apply (e.g., projects that follow strict policies to avoid conflicts). Our results bring quantitative and qualitative evidence related to merge conflict reduction hypotheses and advice raised but not empirically evaluated by previous works, and we also go further by exploring new hypotheses related to contribution modularity and conclusion delay. By finding 15 new merge conflict factors in relation to our previous quantitative study and understanding how interviewees perceive their importance, we derive a set of more robust requirements for the development of more accurate conflict prediction models. Such models could then be used as a basis of project management and assistive tools that could help teams better deal with merge conflicts. Development teams can benefit from these results by improving the recommendations and guidelines to merge conflict avoidance. We also provide ideas on the usefulness and desirable features for the development of a tool for alerting conflict risk.