一位同事和我正在筹划中。用于将我们的开发组转换为使用git作为源控制工具的测试阶段。我们建立了一个强调代码安全性和工作流程简单性的工作流程。但是，在测试不同的合并案例时，我发现git merge会在出现冲突时自动合并差异，而手动合并将是更安全的选择。
实施例：
分支原点/主数据包含一个脚本文件，其函数foo()和bar()作为提交C1。两个用户在其机器上本地检出C1以进行更改。 User1添加了函数baz()并删除了函数foo()。他做了一个快进合并，并将他的更改作为C2推回到origin / master。 User2修改bar()，因此它调用foo()并将其更改提交给C3。他运行一个fetch和merge来引入来自origin / master的任何更改，git执行一个递归合并到C4，导致一个只包含bar()和baz()的文件，其中bar()现在是因为它调用不再存在的foo()而被破坏。
问题： 我意识到我可以设置一个自定义合并驱动程序，以便在这些情况下自动引发冲突（我已经这样做了）以强制手动合并。然而，这似乎是git的一个基本问题，我很惊讶没有其他人在讨论它。我错过了什么，或者是自定义合并驱动程序是处理此问题的最佳方法吗？
最后一件事，我意识到有一些工具可以解决这个问题，但在合并期间修复似乎是最干净，最直接的方法。
编辑：我意识到git无法检测到损坏的代码，但可以检测到文件在最近的共同祖先的两个分支中都被更改了，我认为产生冲突更安全而不是自动合并。我的自定义合并驱动程序实现了这一点，但我想看看是否有更好的方式（TM）。
答案 0 :(得分：4)
这个问题不是git独有的。我所知道的每个版本控制系统都会管理文本冲突，而不是语义冲突。换句话说，git可以检测两个人是否改变了同一行代码。检测您正在讨论的冲突类型的唯一方法是基本上将代码编译为冲突检测过程的一部分。请注意，这并不是一件完全不可行的事情，只是没有人能够解决这个问题。
对于大多数球队来说，这种情况并不常见。如果你遇到很多事情，你可能想看看你的设计的结合，或者你与你的队友之间关于工作分工的沟通。