c# - 如何通过使用 K&R 而不是 B&D 作为编码标准来表明我与 Git 的冲突最少？

Question

Git 很聪明，会“跟随”历史的变化，使合并更容易，对我来说自动合并更多。冲突由围绕更改未更改的线来描述。使用 K&R，您不会像在 B&D 中那样得到只有“{”的模棱两可的行。我将如何测试 Git 在围绕更改的行方面的上下文敏感性限制？

我想避免解决我可能不需要的冲突。但是我需要一些方法来测试通过切换到 K&R 以及它带来的额外上下文可以节省多少潜在冲突。

到目前为止，Git 太聪明了，不会被琐碎的例子所迷惑。

任何帮助表示赞赏。提前致谢。

score 2 · Accepted Answer

这封电子邮件正在讨论 Git 中“耐心”算法的目的。在其中，Bram 解释了多余的匹配行如何产生难以解决的令人讨厌的冲突，但仅在涉及大补丁的相当复杂的合并的情况下。换句话说，简单的人为示例将无法显示此行为。

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

我会说这不是铁定的，但它确实为这个理论提供了一些可信度。

因此，“唯一行”是“不重要行”的简单跨语言代理。

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

score 0 · Accepted Answer

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

score 0 · Accepted Answer

我们有几个大型项目（超过 200 多个代码文件），其中包含大量的 K&R 和 B&D。我可以肯定地说，在使用 Git 近 2 年之后，开发人员疯狂地重构，以及“一天几次”的变基行为，我从来没有因为编码标准的事情而发生过冲突。所以选择任何一个，或两者兼而有之，或两者都不选。没关系。

3 回答 3