Version control 是否有理解代码的源代码管理合并工具？

我最近一直在处理一个大型代码库，进行重构，并普遍改进设计以增加覆盖率。另外，在相当多的文件中，我已经删除了多余的using语句，移动了方法，使类似的功能紧密地结合在一起，添加了区域等，但实际上并没有改变文件中代码的功能

同时，在团队的其他地方，其他开发人员正在修复bug，并在各处更改代码行。显然，当涉及到合并时，这可能是一个问题，因为行号不再匹配，方法可能已经移动

现在，我理解了一条一般规则，即在源代码控制的环境中，移动方法可能是一件危险的事情，我们认为好处大于成本。但我不明白的是为什么会这样

假设我的初始文件是一个简单的计算器：

public class Calculator
{
    public int Subtract(int a, int b)
    {
        return a + b;
    }

    public int Add(int a, int b)
    {
        return a + b;
    }
}

我决定我希望这些方法是按字母顺序排列的：

public class Calculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }

    public int Subtract(int a, int b)
    {
        return a + b;
    }        
}

而另一个开发人员修复了subtract方法中的错误

public class Calculator
{
    public int Subtract(int a, int b)
    {
        return a - b;
    }

    public int Add(int a, int b)
    {
        return a + b;
    }
}

标准的合并工具可能需要您手动合并这两个文件，但是理解代码功能的工具可以轻松地协调这两个更改。这同样适用于删除或添加其他方法、注释、区域或使用语句

因此，（最后！）要问一个问题：是否有任何合并工具能够智能地理解代码的功能，并且可以在没有任何人为干预的情况下合并上面的两个文件？若否，原因为何？这是一个无法解决的问题（当然，这并不像我所暗示的那么简单——但是否因为我看不到的原因而不可能？）

我在我的源代码中使用C#，我很喜欢使用它的东西，但我很感兴趣的是，在编程世界中是否存在这样的东西

---

我已经非常担心这个问题的长度，但编辑后添加了我希望智能源系统如何工作的内容：

在选中初始计算器文件时，系统将解析该文件并创建类的层次结构：

File: Calculator.cs
|
|--Class[0]: Calculator
    |
    |--Method[0]: Subtract
         |
         |--Line[0]: return a + b;
    |
    |--Method[1]: Add
         |
         |--Line[0]: return a +b;

（有额外的支撑线等）

当我签入代码时（使方法按字母顺序排列），它会更新上面的层次结构，这样减法变成方法[1]，加法变成方法[0]

第二个开发人员检查他的代码（显然源代码控制系统知道这是基于原始代码的），并注意到减法中第一行的更改。现在，与其在整个文件中逐行查找该编号，它知道它可以找到一个Calculator.cs/Calculator/Subtract/0，而且该方法已更改位置这一事实并不重要，它仍然可以使合并工作。

我认为这是对您的问题的一个潜在答案。一般的想法是，您不需要对文件进行版本化，只需要对代码块进行版本化。版本控制系统了解代码DOM，并允许您查询代码DOM，以便签出函数、类以及您拥有的用于编辑、编译等的内容

由于方法的顺序不一定重要，因此它们不会以任何顺序存储在数据库中。签出类时，可以指定最喜欢的顺序（字母顺序、公共/保护/私有等）。唯一重要的更改是将

+

切换为

-

的更改。您不会因为重新排列方法而产生冲突

不幸的是，SCID还很年轻，没有太多工具可供使用。然而，在查看和编辑代码的方式上，这是一个非常有趣的演变

---

编辑：

我们的塑料供应链管理方法还远未“完成”，但它已经发布，可以在这种情况下提供帮助。看一看。当然，反馈将非常受欢迎，并将授予一些免费许可证；-）

“自动”对账的结果应该是什么？问题不在于理解语言，而在于理解程序员的意图——这需要心灵感应！我会认为，一个理解代码功能并能将其与布局分离的系统会看到第一个更改纯粹是布局，因此应用于文件布局，第二个更改纯粹是功能，因此将该更改应用于功能更改发生的方法，不管这种方法现在在哪里。我怀疑这样的野兽不存在，但我希望看到其他一些答案。我有一种感觉，这样一个系统将接近人工智能，并将导致天网风投@Neil:这样的合并工具会认识到1）方法增量的顺序已经改变，2）其中一个方法的主体已经改变。因此，结果将是工具将对方法进行重新排序，并应用对方法主体的更改。@martin-但为什么它更喜欢第一种布局而不是第二种布局（反之亦然）？感谢链接，这看起来是正确的想法，很有趣，当我在写“有额外的行用于大括号等…”时在我上面的编辑中，我实际上认为“拧大括号，让源代码管理系统添加大括号，结束标签/空间战争”，但不想掩盖这个问题。很高兴看到我们正朝着这个方向前进，即使我们还没有达到目标。看起来不错，但显然不是我所希望的100%的功能。合并工具是否单独提供？不幸的是，我没有能力组织对我工作的SCM系统进行彻底的更改，但XMerge功能的桌面版本可能非常方便。通常不会，但请在我们的支持电子邮件（支持地址：codicesoftware.com）上给我们发一封信，我们将讨论它，并检查以下内容：，它是我们的新Xmerge，具有更好的重构支持。希望你喜欢！