我如何通过使用K&R而不是B&D作为编码标准来显示我与Git的冲突最少?

所以这是目前为止我发现的最接近的证据。
http://git.661346.n2.nabble.com/Bram-Cohen-speaks-up-about-patience-diff-td2277041.html

这封邮件讨论的是Git中"耐心"算法的目的。在书中，Bram解释了多余的匹配行如何产生难以解决的严重冲突，但只有在涉及大补丁的相当复杂的合并的情况下才会如此。换句话说，简单的人为示例将无法显示此行为。

虽然他也提到了像End这样影响结果的事情，但我们可以推断，在它自己的行上放置一个开始大括号会增加多余匹配行的数量，可能导致这些冲突的更大概率。

我想说这不是铁板钉钉的，但它确实给这个理论提供了一些可信度。

所以"独特的行"是"不重要"的简单跨语言代理行"。

在这个讨论中，这句话对我来说很突出，因为我们基本上是在我们认为重要的行上进行匹配，这些行应该给我们提供上下文，但是大括号本身并不重要，也没有提供上下文。

选择对您/您的团队来说更容易阅读的标准。不管你的源代码管理系统今天表现得如何，明天它会表现得更好，但是你的代码将保持你签入它的方式很长一段时间。

我们有几个大型项目(超过200多个代码文件)，其中包含大量的K&R和B&D的混合物。我可以肯定地说，在使用Git将近2年之后，我的开发团队对重构非常着迷，并且"每天都有好几次"的重基行为，我从来没有因为编码标准的事情而发生过冲突。要么选一个，要么都选，要么都不选。没关系。