当前位置: X-MOL 学术IEEE Trans. Softw. Eng. › 论文详情
Our official English website, www.x-mol.net, welcomes your feedback! (Note: you will need to create a separate account there.)
On the Nature of Merge Conflicts: a Study of 2,731 Open Source Java Projects Hosted by GitHub
IEEE Transactions on Software Engineering ( IF 7.4 ) Pub Date : 2020-08-01 , DOI: 10.1109/tse.2018.2871083
Gleiph Ghiotto , Leonardo Murta , Marcio Barros , Andre van der Hoek

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 percent 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.

中文翻译:

关于合并冲突的性质:对 GitHub 托管的 2,731 个开源 Java 项目的研究

当多个开发人员并行更改一个软件系统时,这些并发的更改需要合并以全部出现在正在开发的软件中。已经提出了许多合并技术来支持此任务,但它们都不能完全自动化合并过程。事实上,据报道,在所有合并尝试中,多达 10% 到 20% 会导致合并冲突,这意味着开发人员必须手动完成合并。迄今为止,我们对这些合并冲突的性质知之甚少。它们看起来像什么,详细说明?开发者如何解决?是否存在任何模式可以建议可以减少手动工作的新合并技术?本文深入研究了在 2,731 个开源 Java 项目的历史中发现的合并冲突。通过对五个项目历史的手动分析,我们对所有 2,731 个项目的自动分析:(1)根据块的数量、大小和所涉及的编程语言构造来表征合并冲突,(2)对手动解决策略进行分类开发人员用来解决这些合并冲突,以及 (3) 分析合并冲突的各种特征与所选择的解决策略之间的关系。我们的结果为未来的合并技术提出了三个主要建议,这些建议在实施后一方面有助于自动解决某些类型的冲突,另一方面为开发人员提供基于工具的帮助,以更轻松地解决其他类型的冲突无法自动解决的冲突。731 项目:(1)根据块的数量、大小和涉及的编程语言构造来表征合并冲突,(2)对开发人员用来解决这些合并冲突的手动解决策略进行分类,以及(3)分析之间的关系合并冲突的各种特征和选择的解决策略。我们的结果为未来的合并技术提出了三个主要建议,这些建议在实施后一方面有助于自动解决某些类型的冲突,另一方面为开发人员提供基于工具的帮助,以更轻松地解决其他类型的冲突无法自动解决的冲突。731 项目:(1)根据块的数量、大小和涉及的编程语言构造来表征合并冲突,(2)对开发人员用来解决这些合并冲突的手动解决策略进行分类,以及(3)分析之间的关系合并冲突的各种特征和选择的解决策略。我们的结果为未来的合并技术提出了三个主要建议,这些建议在实施后一方面有助于自动解决某些类型的冲突,另一方面为开发人员提供基于工具的帮助,以更轻松地解决其他类型的冲突无法自动解决的冲突。(2) 对开发人员用来解决这些合并冲突的手动解决策略进行分类,以及 (3) 分析合并冲突的各种特征与所选择的解决策略之间的关系。我们的结果为未来的合并技术提出了三个主要建议,这些建议在实施后一方面有助于自动解决某些类型的冲突,另一方面为开发人员提供基于工具的帮助,以更轻松地解决其他类型的冲突无法自动解决的冲突。(2) 对开发人员用来解决这些合并冲突的手动解决策略进行分类,以及 (3) 分析合并冲突的各种特征与所选择的解决策略之间的关系。我们的结果为未来的合并技术提出了三个主要建议,这些建议在实施后一方面有助于自动解决某些类型的冲突,另一方面为开发人员提供基于工具的帮助,以更轻松地解决其他类型的冲突无法自动解决的冲突。
更新日期:2020-08-01
down
wechat
bug