Git 解决IDE中的合并冲突，同时保留三方合并信息

（我使用SourceTree作为我的Git工具，Beyond Compare来解决合并冲突，Eclipse作为我的Java IDE。）

冲突非常复杂，我无法在合并工具中解决它，必须手动解决（跨多个文件）

理想情况下，我希望只使用我的代码版本，查看Beyond Compare中的冲突，并使用它来建议我在Eclipse中的更改

不起作用的事情：

如果我只是在Eclipse中打开冲突的版本，那么代码 没有编译，所以我失去了静态类型的所有用处 检查等

如果我只是在Git（SourceTree）中“解析使用我们的/我的”，那么 如果我可以在Eclipse中打开它，那么我就失去了所有漂亮的三方合并 我本可以用来解决冲突的信息

使用主控文件对文件的头版本进行简单的区分 版本也不能解决我的问题-差异太小了 信息。我想要三方信息

---

我是不是走错了路？我应该使用不同的策略来解决冲突吗？在编辑特定版本的文件时，我是否可以使用Git或BC4的功能来单独保存冲突信息

我发现了一些有用的东西（灵感来自Stun Brick的建议）：

启动合并，以便生成本地、基本和远程文件

将这些文件移出到单独的目录中

通过获取本地副本来解决合并（在SourceTree中：Resolve Conflicts->Resolve Using Mine.在Git中：

Git checkout--ours PATH/FILE

）

在Eclipse中打开文件的本地版本

在BC4中打开本地、基本和远程文件

---

现在我可以在Eclipse中编辑我的核心内容，而不会影响BC4的显示。

我个人会将他们的版本复制到Eclipse中，并从中重新引入本地更改。如果您的矿山包含更多的更改，或者重构了大量代码，那么最好从这开始

可以这样做：

在Eclipse中打开正在进行的合并文件（带有愚蠢的合并标记）

在Eclipse中查看提交（使用git插件）

打开文件的特定提交版本（无合并标记）

复制所有内容

同时打开MINE提交的版本并重新引入您的更改，手动继续合并 这应该允许你从一个正在工作的矿井或他们的矿井开始，一块一块地增加

这将允许您仍然使用BC对最显著更改的文件的建议。由于git一次只打开一个文件夹的外部合并，如果需要，您必须手动打开BC中的其他文件

---

然后可以手动将每个文件标记为“已解决”

为什么不将repo复制到另一个目录中，然后在copy目录中运行超越比较，读取它的建议并使用IDE在原始目录中手动应用它们呢？repo有点大，但这给了我一个想法。编辑：见下面我的答案。为什么你会特别打开他们的而不是我的？为了澄清，我的改变是将一些函数从这个文件移到另一个文件中。他们的改变是改变功能内部的东西。在这个特定的实例中，我需要将他们的更改应用到一个与他们实际更改的文件完全不同的文件。不过，总的来说，选择“他们的”还是“我的”肯定取决于上下文？@MarkChimes，他们的，因为我假设你最了解如何引入你的变化。用我的也行。实际上，理想情况下，您应该选择包含最多更改的基础。编辑：但是是的，在你的情况下，最好从重构我的开始。