如何将分支合并回主分支并避免树冲突 - TortoiseSVN

Posted 2023-02-19

【中文标题】如何将分支合并回主分支并避免树冲突 - TortoiseSVN

【英文标题】：How to merge branch back to main branch and avoid tree conflicts - TortoiseSVN

【发布时间】：2014-11-27 02:31:29

【问题描述】：

我使用 TortoiseSVN 在 SVN 中管理源文件。我添加了文件并将它们提交到修订版，随后决定分支。我用我需要的文件进行了分支，并对不打算使用的文件的主干执行了删除。

现在我正在尝试将分支重新集成到主干。 使用乌龟，我已经从树干合并到分支的修订范围，从树干上的删除到头部。这会使分支保持最新状态。

现在我切换到主干，并尝试将分支中的修订合并到主干，合并表明新文件被“跳过”或删除我现在已完成的文件。

在合并到最新的主干时我是否遗漏了什么？

【问题讨论】：

合并回主干时是否使用了 --reintegrate 标志？请注意，当您重新集成时，您将无法再使用您的分支。

Subversion 的最后几个版本不再使用--reintegrate，并且应该会为您处理这个问题。

如果这里的任何答案对您有所帮助，请“接受”其中一个，以便其他人可以从这个问题中受益。

【参考方案1】：

为了进行重新集成，您需要合并来自Trunk 的所有修订，这些修订发生在您分支到要重新集成的分支之后。

下面是一个例子：

上一个版本...

Rev 20

- (Trunk) 提交新文件

Rev 21

-（功能分支）创建功能分支

Rev 22

- (Trunk) 从

Rev 20

中删除文件

Rev 23

- (Trunk) 处理随机文件

Rev 24

-（Feature Branch）处理其他随机文件

Rev 25

- (Feature Branch) 将修订版

22

和

23

合并到 Feature Branch

Rev 26

- (Trunk) 将功能分支重新集成到 Trunk 中

您会注意到，我们将删除您的文件（Rev 22）作为合并到功能分支（Rev 25）的一部分。

现在这给你带来了一个新问题：

当您在 Rev 25 期间合并来自 Trunk 的更改时，您希望在 Feature Branch 中拥有的文件将被删除。关于Trunk 中实际发生的事情，这是真实而准确的。您将有多种选择：

如果在 Rev 24 期间在 Feature Branch 中修改了 Trunk 中删除的文件，则在尝试按照 Rev 25 进行合并时，您将收到树冲突强>。您可以在执行合并时使用本地更改简单地将冲突标记为已解决。 将Rev 22 合并到Feature Branch 中，然后执行任何其他必要的合并到Feature Branch 中（这应该等同于我在#1 中提到的）李> 按照 Rev 25 执行合并到 Feature Branch。合并完成后，您可以查看 Feature Branch 的日志并恢复在 Rev 25 中所做的更改（合并本身），通过挑选文件并恢复每个文件来删除您的文件。这些恢复会将文件恢复为新文件，以添加到Feature Branch 的存储库中。 请注意，这些文件在历史记录中与原始文件不同。就 SVN 而言，这些文件被视为全新文件，因此它们不会与原始文件共享任何祖先。

【参考方案2】：

Subversion 合并需要一些东西：

共同祖先

您认为这很简单，但这种情况经常发生。我见过开发人员会使用svn mkdir 创建一个分支，检查该分支，将文件从主干复制到该分支，然后执行svn add 将它们添加回。

虽然分支和主干具有相同的名称和相同的结构，但 Subversion 将它们视为两个完全独立的文件。树干和那个分支之间没有共同的历史。当然，开发者应该已经使用svn cp将主干复制到分支。

但是，您可以在较小的部分中遇到此类问题。想象一下，开发人员以正确的方式创建分支。然后发现项目中缺少一些*.jpg 文件。开发人员签出分支并添加文件。都照顾好了。现在，开发人员意识到主干上也存在相同的错误。没问题，结帐后备箱添加缺少的*.jpg 文件。

当然，主干上的*.jpg 文件与分支上​​的文件不同。开发人员应该将那些 *.jpgs 从分支创建的修订版合并到主干。

修订冲突

Subversion 不合并分支：它合并更改。这是一个难以理解的概念，但它赋予了 Subversion 很大的合并能力。

我在修订版 100 上从主干创建了一个分支。

分支的修订历史

100：已创建分支 103：错误修复 2001 110：将主干合并到分支 112：进行了更多更改

主干的修订历史

102：更改 104：错误修正 2001 111：更改

现在我想将我的分支合并回我的主干。如果我没有指定要使用的修订版，Subversion 会尝试找出我需要合并哪些修订版。我从来没有将我的分支合并到我的主干，所以 Subversion 看到我的分支和主干之间的最后一个共同祖先是修订版 100。然后它看到我需要将更改 103、110 和 112 合并回我的主干。

但是，我分支上的修订版 110 是我已经合并到我的主干的更改！如果我不小心，我会尝试将这些更改合并回我的主干中，从而导致冲突。

Subversion 应该可以处理这个问题，但并不总是那么干净。在运行合并之前，请执行以下命令：

$ svn mergeinfo --showrevs eligible $URL/branches/branch

这将显示 Subversion 想要合并到我的主干的修订。我应该查看该列表并确保这些更改尚未出现在我的后备箱中。

假设我查看了这个列表，发现这个符合条件的列表包含修订版 103、110 和 112。请稍等。修订版 103 修复了 Bug 2001，但这已经在主干上修复了。出于某种原因，还列出了修订版 110，修订版 110 是我的主干到我的分支的合并。我也不希望考虑这个修订。

我需要做的是通知 Subversion 不要考虑这些修订：

$ svn merge --record-only -c 103 -c 110 $URL/branches/branch
$ svn commit -m"Updating merge information to prevent collisions with 103 and 110"

现在，我再次运行svn mergeinfo --showrevs eligible，这两个修订版不会列出。我基本上已经通知 Subverison 这两套改动已经在我的后备箱里了。

您始终可以使用--dry-run 在完成之前尝试合并。如果您指定要合并的修订版，Subversion 合并始终有效。当您尝试让 Subversion 自行跟踪合并时，往往会出现问题。它肯定比以前好，但 Subversion 可能会与复杂的环境混淆。我们有一个项目重命名了分支，替换了主干，并在主干和其他两个分支之间进行了合并。 （不要问为什么。）。

开发人员无法进行合并，因为他们最终产生了数百个冲突。查看符合条件的修订，我能够清理混乱，并让合并工作。

记住要尽早并经常合并：合并的次数越多，合并就越有可能奏效，并且很容易发现任何冲突。尽量保持简单的合并活动。如果你在两个不同的分支上修复了一个 bug，你需要通过svn merge --record-only 让 Subversion 知道。

无论你做什么。不要惊慌。冲突会发生，如果你知道如何解决它们，你就可以避免合并地狱。