这是场景：

• User1，Branch1：添加“abc.def”；提交。
• User2，Branch2：添加“abc.def”（相同的文件名，但文件中的更多详细信息）；提交。

现在 User1 想要合并“abc.def”文件的更新版本。因此（使用 TortoiseSVN 1.7.10），User1 从 Branch1 的工作副本开始，选择Merge...-> Reintegrate a Branch，然后选择 Branch2 并选择Merge。可以预见的是，会产生“树冲突”，并带有以下文本：

最后一次合并操作尝试从 Branch2 添加文件“abc.def”，但该文件已在本地添加。你想如何解决这个冲突？

但唯一的选择是标有 的单个按钮Keep the local file。没有选择远程文件的选项，这是 User1 真正想要的文件。

我在这里做错了什么，我该如何解决？更具体地说，如何将 User2 的文件版本放入 Branch1？

（当然，我确信 User1 可以在合并之前手动删除文件，但这会抹掉 User1 可能想要保留的任何历史记录。另外，这只是一个笨拙的工作流程，尤其是当这种困境中存在大量文件时。）

不幸的是，在关于树冲突的 TortoiseSVN 文档中甚至没有提到这种情况

更新：

除了选择“ Reintegrate a Branch”我还尝试过“ Merge a Range of Revisions”和“ Merge two different trees”。对于后一种情况，我选择远程分支（Branch2）作为“开始”，选择本地分支作为目标（Branch1；在添加文件之前选择修订版。）在所有情况下我都得到了相同的结果：树与没有选择文件的 User2 版本的选项发生冲突。

更新#2：

根据文档，“合并进度对话框中应该有一个名为Merge non-interactive”的复选框，如果未选中，则应该在合并期间打开“合并冲突回调对话框”。但是，我在合并过程中找不到任何这样的复选框。它在哪里？

我在一个新的空 SVN 存储库中重新创建了我的问题：

修订版 1：

• /树干/
• /分支机构/

操作：将文本文件“init.txt”添加到分支“trunk”

修订 2：

• /trunk/init.txt
• /分支机构/

操作：基于主干创建特征分支

修订版 3：

• /trunk/init.txt
• /branches/featureA/init.txt

操作：为分支添加不稳定的特性

修订版 4：

• /trunk/init.txt
• /branches/featureA/init.txt
• /branches/featureA/unstable.txt

操作：通过添加文件“bugfix.conf”修复功能分支中的错误

修订版 5：

• /trunk/init.txt
• /branches/featureA/init.txt
• /branches/featureA/unstable.txt
• /branches/featureA/bugfix.conf

操作：将“bugfix.conf”合并回主干但跳过“unstable.txt”

第一个合并对话框页面的屏幕截图

第二个合并对话框页面的屏幕截图

修订版 6：

• /trunk/ [svn:mergeinfo=/branches/featureA:3,5]
• /trunk/init.txt
• /trunk/bugfix.conf
• /branches/ [无 svn:mergeinfo]
• /branches/featureA/init.txt
• /branches/featureA/unstable.txt
• /branches/featureA/bugfix.conf

操作：在文件“init.txt”trunk处继续工作

修订版 7：

• /trunk/ [svn:mergeinfo=/branches/featureA:3,5]
• /trunk/init.txt（新内容）
• /trunk/bugfix.conf
• /branches/ [无 svn:mergeinfo]
• /branches/featureA/init.txt（旧内容）
• /branches/featureA/unstable.txt
• /branches/featureA/bugfix.conf

操作：尝试将特性分支与主干同步

预期结果： 修订版 8：

• /trunk/ [svn:mergeinfo=/branches/featureA:4]
• /trunk/init.txt（新内容）
• /trunk/bugfix.conf
• /branches/ [svn:mergeinfo=/trunk:6]
• /branches/featureA/init.txt（新内容）
• /branches/featureA/bugfix.conf

第一次尝试

在功能分支上选择“合并一系列修订 -> 所有修订”

错误：“仅当修订版 3 到 7 先前从 /branches/featureA 合并到重新集成源时，才能使用重新集成，但情况并非如此：主干缺少范围 /branches/featureA:4”

为什么 SVN 需要修订 4 也被合并？为稳定和不稳定建立一个单独的分支的全部意义在于使一些提交远离另一个分支。更改（添加文件不稳定.txt）完全独立于其他更改。

第二次尝试

在功能分支上选择“合并一系列修订 -> 修订 2-7”（我可以手动选择的所有修订）

错误：“树冲突：最后一次合并操作尝试添加文件 'bugfix.txt'，但该文件在工作副本中被阻塞。”

TortoiseSVN 允许我选择 Revision 6 进行合并，即使合并此更改没有意义，因为它已经包含在目标分支中，因为它最初是在 Revision 5 中提交的。为什么 TortoiseSVN 不能自动处理这个？是否不支持在主干和功能分支之间挑选/合并单个提交？

我正在制定一个例程，在每次合并之前执行。它将运行单元测试并检查其他配置文件。仅供参考，它是在节点中编码的。

最后，如果一切正常，它会检查是否与 有任何冲突develop，并输出yes或输出no给用户。拉取请求应该在 gitlab 上管理，而不是在本地分支上。所以不应该在本地分支上进行“真正的”合并。

有没有可用的 git 命令git -conflitcs-with-this-branch？还有一种从nodejs中检索它的方法？

谢谢，

斯蒂芬。

在该分支将 TRUNK 合并到其中之后，我遇到了数十个多余的树冲突，试图将一个颠覆分支合并回 TRUNK。以下是按时间顺序发生的事情。

1. 分支由 TRUNK 制成，对 A 进行了编辑
2. 文件被添加到 TRUNK 到 B
3. 我将 TRUNK 合并到我的 BRANCH 中，并通过svn log验证添加到我的分支的文件和目录 B 保留了它们从主干编辑的历史记录。
4. 在我的分支中，我更改了集合 B 中的一些文件，这些文件是在步骤 3 中从 TRUNK 合并的
5. 我尝试将我的分支合并到 TRUNK

在我的合并过程中，在第 3 步中添加到我的分支的 B 中的所有文件都显示为树冲突 。这些文件中的绝大多数都没有被我以任何方式触及。

B 中标记为树冲突的文件的一小部分实际上已在我的分支中进行了更改，但就 svn UI（命令行或 GUI）而言，这些文件与我未修改的大量文件无法区分。

我绝对不想手动检查数百个文件以查找需要合并的十几个文件，但我也不知道是否有某种方式可以让某些 svn 客户端或工具自动为我执行此操作。

关于解决这个问题有什么建议吗？

如何轻松地在 git 中的 rebase 末尾修复冲突的 rebase 分支？

例如，我在一个功能分支上，并且在主分支中有 2 次提交用于 rebase。
第一次提交会产生冲突，但是如果 rebase 将两个提交结合在一起，那么在第二次提交之后就不会发生冲突。
那么如何将它作为一个整体重新定位，而不是一个一个地重新定位它并解决两次冲突呢？

我认为它必须在某个地方回答，但我找不到任何东西，因为所有类似的问题标题都含糊不清。

注意：此问题的基本情况也是此处略有不同的问题的一部分。

情况

我有一个树干，早些时候，一个分支是由它制成的。然后，在主干中进行了一些文件重命名。这些重命名是由“复制/删除”意外进行的，而不是应有的正确 svn 重命名过程。TSVN 文档中对此进行了描述，在我的情况下，省略了“修复移动”。

现在我有树冲突，将分支合并回树干时：

• 合并工具无法识别这些重命名，并将它们报告为树冲突
• 虽然“新的交互式冲突解决程序”应该找到此类错误的重命名，但它似乎只对传入的更改这样做，而不是针对目标中的更改（在我的例子中是主干）。

问题

• 事后，我可以添加关于这些“复制/删除”重命名的元信息，以便 Subversion 现在可以识别它们吗？

Note: The underlying situation of this question is also part of a slightly different question here.

Situation

I have a trunk, where earlier, a branch has been made from. Then, in the trunk some file renamings have been made. These renamings were accidentially made by "copy/delete", not with the proper svn rename process as they should have. This is described in the TSVN docs, and in my case the "Repair move" was omitted.

Now I have tree conflicts, when merging the branch back to the trunk:

• the merging tool does not recognise these renamings, and reports them as tree conflict
• While the "New interactive conflict resolver" should find such faulty renames, it seems to do so only on incoming changes, not for those in the target (trunk in my case).

Question

• Can I tell the conflict resolver to look for structural changes in the target (local files), not the incoming tree?

我认为我的标题不够清楚，所以我将描述问题：

在我的 git 项目中，我有 3 个分支：master、b1和b2. 这是历史树：

假设我想重新设置b1分支并编辑E提交。变基后，提交E并将F被新的提交替换，E'并且F'具有不同的提交 SHA。因此， 中的历史b1将不同于 中的历史b2：

所以我的问题是：如何确保在变基之后b2遵循b1（自动获得与 相同的新提交b1），b1以便它们各自的历史保持一致。

早上好，让我解释一下我的问题：

• 在 SVN 中，我有一个主干 DEV 和一个功能分支 FB01
• 在最近一次项目文件夹的重组过程中，在 FB01 的工作副本中执行了海量文件删除操作。然后在单个修订版中将更改提交到 FB01，以及对其他一些文件的修改。
• 同时对trunk进行了同样的海量文件删除操作

假设具有以下结构

现在在 DEV 和 FB01 中都删除了 file1，在 FB01 中修改了 file2

将 FB01 合并回 DEV，很多关于文件删除的树冲突都需要手动忽略每次删除。有人可以建议我一种从合并中排除所有删除的方法吗？

假设我克隆了一个远程存储库，到目前为止它有 1 个 commit => A。然后，我对我的本地分支进行了两次提交，所以它变成了 => A - B - C。但是，我的同事同时向他们的本地分支提交了另外两个提交，所以他们的提交历史变成了 => A - D - E。然后他们将其推送到远程存储库。

然后我意识到我想推送我的更改，但git push告诉我远程存储库在我前面。所以，我愿意git pull。

我的问题是，现在跟踪远程跟踪分支的本地分支是什么样的？我知道会有合并冲突，但我的实际问题是：提交历史会是什么样子？

更具体地说，假设我修复了冲突并现在提交了它们，我的提交历史会看起来像这样A - D - E - F还是A - B - C - D - E - F？git中的提交历史是非线性的吗？