如何处理Git持续集成合并冲突

Question

7

我们正在制定和为Git集成做准备，我们正在实施与以下链接类似的设计。

我们遇到的问题是当您提交并推送到“develop”分支或持续集成分支时，由于我们有多个团队在不同的分支上工作，您很可能会遇到合并冲突，因为您从未在推送之前从“develop”中拉取。对于推动团队来说，试图解决他们几乎没有任何知识的事情似乎不是最佳实践。

我们想到的一个想法是在“develop”分支上进行拉取请求，并有一个专门的团队来解决这些问题。

我们是否错过了任何选项？

- Adam

2个回答

0

如果你：

那么这将永远不会成为问题。你的合并冲突总是会在开发机器上发生，你可以手动解决它们。

- NightOwl888

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- mproffitt · Accepted Answer

特性分支的概念是它们只应该包含一个小的、原子性的变更。根据理论，这种变更由于其本质不应该引起合并冲突。

如果一个特性正在引入合并冲突，我倾向于检查您认为什么是“特性”。

我经历过的方式是，一个特性与一个具体的任务有关，这个任务（按时间计算）应该持续一两天。

鉴于这种短时间段，合并冲突不太可能在周期内出现，但是在这种情况下发生，例如当您有多个团队在同一代码库区域工作时，需要一定程度的沟通以确保冲突以正确的方式解决。

有不同的模型可以帮助您管理冲突解决。我们使用水平切片模型，如果多个团队需要在特定区域的代码库中进行更改，则分配给项目涵盖该给定模块的团队。如果您的公司更喜欢垂直切片模型，那么跨团队发生合并冲突的可能性就较小。

没有任何工具能比对话更好地解决冲突。如果您知道自己的更改将影响到其他人正在处理的文件，最好的做法是进行对话。

在某些情况下，这可能不是理想的选择，业务可能有其他关于哪些更改何时发布的想法，但只要每个开发人员都使其特性分支与develop保持最新，冲突的倾向就会大大降低。