问题标签 [3-way-merge]

当 Bazaar（和许多其他 dvcs）中发生文本冲突时，会生成 .BASE、.THIS 和 .OTHER 文件。然后由用户使用 3 路合并工具来合并冲突，然后将其标记为已解决。

我想在 Eclipse 中获取所有已注册的合并查看器，并为用户提供一个选项以将冲突与其中任何一个合并。（TextMergeViewer 是默认选项）。我怀疑我需要一些如何以编程方式向这些合并查看器提供 3 个文件，并且可能编写一些自定义代码来包装 BASE、THIS 和其他文件，以告诉合并查看器差异在哪里。（解释“人字形”标记，如<<<<<<<. 等）

git的合并冲突解决本质上是否比其他 SCM（CVS、Subversion 等）以及独立的合并工具更有效？如果是这样，为什么？

澄清：这里我对算法本身更感兴趣——它与普通的 diff3 方法有什么不同吗？
有些工具声称在这方面更智能（例如 Guiffy），是否值得将其作为 git 合并工具插入？git 在确定文件内或文件间移动的文本方面是否更聪明？（而不是报告嘈杂的冲突。我从 Linus 的谈话中对此有一个模糊的印象）。

背景：刚刚进行了一次巨大的合并，使用git-svn它导致的冲突比我使用普通的一半svn merge（第一次合并没有跟踪）..所以我想了解原因。

它们是类似的 Qs/As，但它们更多的是关于过程的大图，以及合并如何更自然地适应。为此，git“针对合并进行优化”（而不是仅分支），实际上是否意味着：

1. 更少的手动冲突——更好的自动解析算法（例如，重命名处理得很好）
2. 更安全的操作——自动解决留下更多/只有真正的冲突和更少的错误警报
3. 更快的操作——比如说，由于精益和平均对象模型
4. 更好的工具——这使得体验不那么痛苦，例如基于 DAG 的合并跟踪、mergetool、历史查询/可视化、stash、rebase 等...
5. 别的东西
6. 以上的组合

? 现在，我对 1 和 2 最感兴趣。

我在一个由 3 名开发人员组成的团队中工作，我们最近从 CVS 切换到 Mercurial。我们通过在每个工作站上都​​有本地存储库并拉/推到开发服务器来使用 Mercurial。我不确定这是最好的工作流程，因为在提交后很容易忘记推送，并且 3 路合并冲突会导致真正的头痛。有没有更好的工作流程我们可以使用，因为我认为分布式 VC 的复杂性目前超过了好处。

谢谢

我正在做一个项目，我有一个提交，该提交引入了一个没有立即发现的主要问题的功能。现在我想完全删除该修订，同时保持其工作，但我很难围绕这个 3 路合并。这是我的项目的简化图。

如果我理解正确的话，r127 和 r134 是完全一样的。当我hg up -C -r 133然后运行hg merge时，Meld 会弹出我的文件之一的三种形式：本地、基础和其他。本地似乎是 r133，但我很难理解“基础”和“其他”的含义。

所以，我已经成功地弄清楚了如何使用 Windows 7 使用命令行颠覆和 Beyond Compare 3 进行简单的 diff 和 3 方式合并。谢谢你，stackoverflow。

但是，我经常有很多文件在两次提交之间进行更改，即 html 文件、css 文件和 javascript 文件都与同一个 bug 修复相关。当我使用内置的 svn diff 时，我只需输入“svn di”，它就会显示所有文件中所有 diff 的列表。有没有办法用 Beyond Compare 3 触发这种类型的功能？

目前，当我输入“svn di”时，它会将第一个文件发送到 Beyond Compare，当我检查完更改后，我关闭了 Beyond Compare 窗口，diff 结束。如果不手动输入每个名称，我就无法区分其他文件。（有时我不记得我改变的所有内容......基本上，它变得非常混乱。）

这甚至可能吗？如果是这样，怎么做？

谢谢。

我对 TFS 很陌生，但我对 VSS 有一些经验。我想知道您对在以下情况下使用 TFS 的最佳方式的看法：我们是一组从事项目的开发人员。所有项目都从一个共同的基础代码开始。所有项目都只有一个人，在项目完成之前没有代码共享。一个项目可以持续几个小时到几个月，在完成之前不会合并任何代码。任何开发人员同时在多个项目上工作，通常一次有 7-10 个项目。通常项目只涉及少量更改/创建的文件 (10-20)，但依赖于大量经常更改的基础设施文件。但是，在合并之前不会考虑基础架构的任何更改，因此在最终构建之前我们不会从服务器获取最新版本。

另一个要求是，在合并时，我们希望使用 3 路合并工具。我们通过定制的应用程序在 VSS 中使用这种方法，并且效果很好。然而，这涉及到特殊的文件管理，例如，每个必须更改的文件都必须在某处保存一个原始版本，该版本将用作 3 路合并过程的“根”文件。

你怎么看？

我开始在 Windows 上使用 TortoiseGit，但我发现有些事情很烦人。例如，当我在合并期间发生冲突时，我需要执行以下操作：

• 做3路合并（当然......没有其他选择）
• 将文件标记为已解决

如果合并成功结束，是否有自动将文件标记为已解决的方法？

感谢您的任何指点，

尤利安

假设我在文档中处于状态 A。然后我进行更改 B、C 和 D（按顺序）。

有没有办法可以保留更改 B 和 D，但跳过 C？

或者，假设我在文档中处于状态 A。我进行更改 B，撤消它，然后进行更改 C 和 D（所以 Vim 有一个带有两个分支的撤消树）。然后我改变主意并决定我想使用 B 和 D 而不是 C。

我怎样才能在 Vim 中做到这一点？我已经gundo.vim安装了插件，但我没有用过那么多。

我可以将 TortoiseHg 配置为在需要 3 路合并时启动 Beyond Compare 3，但我无法让它显示正在比较的文件的名称和版本。它在进行 2 路文件比较时显示文件的名称和版本。有谁知道如何正确配置它？KDiff3 也有同样的问题。

按照 BC 支持站点 ( http://www.scootersoftware.com/support.php?zz=kb_vcs ) 上的指示，将 BC3 设置为 3 路合并工具，但它不显示文件名或版本。

使用 mercurial 和 Beyond compare 3(bc3) 作为差异工具？需要帮助几乎可以回答这个问题。它适用于 2 路比较，但不适用于 3 路合并。谁能告诉我如何解决这个问题？

我不得不再次合并分支之间的代码，而文本合并工具在项目文件中发现了很多冲突。

我希望理解项目文件（文件添加/删除和编译选项已更改）的工具可以轻松地进行 3 路合并。

有这样的工具吗？

（无论好坏，我们都有由不同客户支付（和控制）的长期分支机构，以及所有新客户的“主要”分支机构，因此目前无法选择持续集成。）