2

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

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

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

不起作用的事情：

  1. 如果我只是在 Eclipse 中打开有冲突的版本，那么代码不会编译，所以我失去了静态类型检查等的所有用处。
  2. 如果我只是在 Git (SourceTree) 中“使用 ours/mine 解决”以便我可以在 Eclipse 中打开它，那么我会丢失所有可以用来解决冲突的漂亮的三向合并信息。
  3. 用主版本对文件的 HEAD 版本进行简单的差异也不能解决我的问题 - 差异的信息太少。我想要三方面的信息。

我是以错误的方式接近这个吗？我应该使用不同的策略来解决冲突吗？是否有 Git 或 BC4 的功能可用于在编辑文件的特定版本时单独保留冲突信息？

4

2 回答 2

1

我发现一些可行的方法（受 Stun Brick 建议的启发）：

开始合并，以便生成 LOCAL、BASE 和 REMOTE 文件。

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

通过获取本地副本来解决合并问题（在 SourceTree：解决冲突 -> 使用我的解决方案。在 Git 中：）git checkout --ours PATH/FILE。

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

在 BC4 中打开 LOCAL、BASE 和 REMOTE 文件。

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

于 2018-07-17T10:03:12.150 回答
1

就个人而言，我会将 THEIRS 版本复制到 Eclipse 中，然后从那里重新引入本地更改。如果您的 MINE 包含更多的更改，或者重构了大量代码，那么最好从它开始。

这可以这样做：

  1. 在 Eclipse 中打开正在进行的合并文件（带有愚蠢的合并标签）
  2. 在 Eclipse 中查看 THEIRS 提交（使用 git 插件），
  3. 打开特定提交的文件版本（无合并标签）
  4. 复制一切。
  5. 同时打开 MINE 提交的版本并重新引入您的更改，手动继续合并。

这应该允许您从工作的 MINE 或 THEIRS 开始，逐个添加。

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

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

于 2018-07-17T10:14:50.323 回答