Git非常聪明，并且会“跟踪”历史记录中的更改，以便更轻松地进行合并，并为我自动合并。冲突由围绕变更未改变的线描绘。使用K＆amp; R，你就不会像在B＆amp; D中那样只有“{”的模糊线条。我如何根据围绕变化的线条测试Git对上下文敏感度的限制？
我想避免解决我可能不需要的冲突。但是我需要一些方法来测试我将通过切换到K＆amp; R以及它带来的附加上下文来节省多少潜在的冲突。
到目前为止，Git太聪明了，不会被琐碎的例子所迷惑。
感谢任何帮助。提前谢谢。
答案 0 :(得分：2)
所以这是迄今为止我发现的最接近的证据 http://git.661346.n2.nabble.com/Bram-Cohen-speaks-up-about-patience-diff-td2277041.html
电子邮件正在讨论Git中“耐心”算法的目的。在其中，Bram解释了多余的匹配行如何能够创建难以解决的讨厌冲突，但仅限于涉及大补丁的相当复杂的合并。换句话说，简单的人为例子将无法显示这种行为。
虽然他也提到像End这样影响结果的事情，但是推断在它自己的行上放置一个开口括号会增加多余匹配线的数量可能会导致这些冲突的可能性更大。
我认为这不是铁腕，但它确实为这一理论提供了一些信任。
所以'unique lines'是一个简单的跨语言代理，用于'不重要 线。
在这个讨论中，这个引用对我来说很突出，因为我们基本上匹配了我们认为应该为我们提供背景的重要线条，但是支撑本身并不重要，并且不提供背景。
答案 1 :(得分：0)
挑选标准，让您/您的团队更轻松地阅读其他内容。无论您的源代码控制系统如何表现如今，它明天都会表现得更好，但您的代码将保持您长时间检查它的方式。
答案 2 :(得分：0)
我们有几个大项目（超过200多个代码文件），其中包含K＆amp; R和B＆amp; D的大量混合。我可以肯定地说，经过近2年的Git，一个重构疯狂的开发人员和“一天几次”的变相行为，我从来没有因为编码标准事情而发生冲突。因此，选择任何一个，或两个，或两者兼而有之。没关系。