2

我和一位同事正处于计划和测试阶段,将我们的开发团队转换为使用 git 作为源代码控制工具。我们建立了一个强调代码安全性和工作流程简单性的工作流程。但是,在测试不同的合并案例时,我发现在git merge出现冲突时会自动合并差异,而手动合并将是更安全的选择。

示例:分支 origin/master 包含一个脚本文件,该文件具有功能foo()bar()作为提交 C1。两个用户各自在他们的机器上本地签出 C1 以进行更改。User1 添加功能baz()并删除功能foo()。他进行了快进合并并将他的更改推回原点/主控作为 C2。User2 进行修改bar(),因此它调用foo()并将他的更改提交给 C3。他运行 fetch 和 merge 以引入来自 origin/master 的任何更改,并且 git 执行递归合并到 C4 中,这导致文件仅包含bar()并且baz()wherebar()现在被破坏,因为它调用foo()不再存在。

问题:我意识到我可以设置一个自定义合并驱动程序以在这些情况下自动引起冲突(我已经这样做了)以强制手动合并。然而,这似乎是 git 的一个基本问题,我很惊讶没有其他人在讨论它。我是否遗漏了什么或者自定义合并驱动程序是处理这个问题的最佳方法?

最后一件事,我意识到有一些工具可以事后解决这个问题,但在合并期间进行修复似乎是最干净、最直接的方法。

编辑:我意识到 git 无法检测到损坏的代码,但它可以检测到文件在最近的共同祖先的两个分支中都发生了更改,我认为产生冲突比自动合并更安全。我的自定义合并驱动程序实现了这一点,但我想看看是否有 Better Way(TM)。

4

1 回答 1

4

这个问题不是 git 独有的。我知道的每个版本控制系统都管理文本冲突,而不是语义冲突。换句话说,git 可以检测两个人是否更改了同一行代码。检测您正在谈论的冲突类型的唯一方法是将代码编译为冲突检测过程的一部分。请注意,这并不是一件完全不可行的事情,只是还没有人解决它。

对于大多数团队来说,这种情况并不经常出现。如果它经常发生在你身上,你可能想看看你的设计的耦合,或者你和你的队友关于工作是如何划分的沟通。

于 2013-02-27T19:54:47.633 回答