Version control 什么是「；“合并基础”；在MKS？

通过阅读MKS完整性手册，我看到以下内容：

• “合并自”是从中合并块的修订版
• 合并基准是要用作合并基准的修订版 根据要应用于的合并计算差异 合并到
• 合并到是工作文件，用作 合并结果文件

我不太明白的是，“合并基数”到底是什么？如果我有一个新的沙盒，我假设我有最新的沙盒，那么，如果我要将分支的更改合并到此沙盒，为什么MKS merge工具会显示第三个文件（合并基）？这个文件来自哪里？为什么我可能会关心这个问题？我只想知道我沙盒中的文件（合并到）和分支上的文件（合并到）之间的区别

---

我已经在合并工具中关闭了它的显示，但是，显然有人认为它足够重要，可以在手册中显示和编写，所以我想更好地了解它是什么，以及为什么我可能（或可能不）关心它。

从我的理解来看，这就是合并的全部内容

因此，您创建了一个分支来更改代码，原因是您以后希望将代码集成（合并）回主干

创建分支的“分割点”用作合并基。然后，MKS合并工具使用此版本查找并最终评估相关更改

如果主干上没有更新的版本，那么合并基础就是来自沙箱（主干）的文件

但是如果主干上有更新的版本（意味着您/某人也在主干上开发），那么它不是将主干的头部与分支的选定版本合并，而是查看每个代码行（分支、主干）与合并基础之间的差异

所有这些也适用于分行/支行合并

我必须承认，这（对于初学者来说）确实是一件具有挑战性的事情，如果您以前在同一个文件上进行过多次合并，那么这将变得更加复杂。因为上述参数将发生变化，因此合并基数将计算回上一次合并

---

我希望这有点帮助。如果不只是注释…

那么，合并基数实际上是一个固定点，而不是用于计算差异的“我想要”版本。好吧，这更有意义。我认为（从合并基础评估分支和主干上的更改）就是为什么它会将一些合并（从分支）的更改标记为“冲突”，即使它已正确地排序了冲突的更改，并且我只需要保存结果文件？