每当我在SCM中看到类似导入或方法签名更改（例如重命名变量）之类的冲突时，我想知道是否有类似语言感知的diff / merge方法可以处理更烦人的小变化发生在共享项目上。 在Unix环境中有什么能够更顺畅地处理冲突吗？
答案 0 :(得分：5)
我同意如果这样的工具存在会很棒，但是我没有意识到这一点。我认为没有的原因是因为每个SCM的合并算法（无论是git，hg，bzr，svn等）都适用于最小公分母，它只是纯文本。为了使这些SCM工具真正理解语言语法和语义，他们必须包括解析语言的能力。对于任何SCM来说，包含解析Java，C＃，Python，Ruby，Groovy，C，C ++等的能力似乎都是一项太大的任务，更不用说这些语言中的每一种都有不同的语法版本（例如，Java泛型在1.5之前不存在）。因此，SCM必须包括检测或配置为知道源代码所用语言的语言和版本的能力。
我认为更有可能在第三方合并工具中找到任何依赖于语言的合并功能（例如.gitconfig中的合并＆gt;工具设置和.hgrc中的ui＆gt;合并设置）。可以将此工具配置为知道项目中的任何.java文件都是用Java 1.6编写的，然后使用JDK中的解析功能生成AST并对更改是否有意义执行一些“深入”分析在那种语言的背景下。
答案 1 :(得分：2)
我正在寻找完全相同的东西。 那些合并工具供应商可能应该解决这种语义，语言感知的合并..如果没有，我将不得不成为一个：）
目前，作为一个穷人的伎俩，我有时会通过Eclipse的代码清理/组织进口/订单成员将3个文件（基础，我们的，他们的）文件预处理为他们的“规范形式”。
虽然有限，但这很好用：上次它将冲突数量减少到大约200到2.我打算将它包装成一个脚本，并插入到git的合并工具中。
还编写了脚本autoresolve java import conflict，它只保留导入的两面并添加注释来解释正在发生的事情以及todo：'组织导入'。
答案 2 :(得分：0)
您可能希望让团队中的每个人共享相同的IDE设置，例如导入顺序，格式等，以避免首先发生此类冲突。
答案 3 :(得分：0)
没有git rebase解决这个问题？ 任何变量重命名都将在相关的提交中进行说明。 git rebase让你与上游提交保持同步。如果经常变换（每天ish？），你不应该得到像这样的愚蠢冲突，如果你是，它们可能是真正的冲突，而不是由java语法解析器解决。
答案 4 :(得分：0)
让任何人登陆此页面更容易。 这个问题是http://stackoverflow.com/questions/523307/semantic-diff-utilities的愚蠢（在主要问题中答复了，但并不明显）
我所知道的当前工具（上面这个任务的答案）是symantic merge - https://www.semanticmerge.com