问题标签 [merge-conflict-resolution]

当 Git 中存在合并冲突时，会在冲突文件中插入如下垃圾。三个问题：

1. 您如何阅读这些注释？
2. 修复这些合并冲突时可以使用哪些策略？
3. 是否有适用于 Mac 的 GUI 工具知道如何读取这些文件并并排显示两个版本以更轻松地解决问题？

注意：如果相关，我使用的是 GitHub 的 Mac GUI 客户端。

我正在使用 Dropbox 作为 git 存储库。

现在由于同步中的一些问题，git 中存在一些冲突的副本。如何消除此冲突？由于此冲突，我无法克隆该存储库的内容。

我在克隆存储库时遇到的错误是：-

Git :- 致命：参考的格式无效：'refs/heads/debugging (xyz conflictedcopy date)'

我刚刚用 Git 做了以下事情，但我不确定这是否是正确的做事方式。我所拥有的是一个包含一些东西的文件。然后有一个分支向这个文件添加额外的东西（扩展它，它是我们单独出售的插件）。假设 branch1 和 branch2 有一个包含以下内容的文件：

然后我在 branch1 的一个主要特性上做了一些工作，并对该分支进行了提交。之后，我将 branch1 合并到 branch2 以将此新功能也重新应用于文件的插件版本。现在文件是

但是代码不能完全工作，我现在需要切换到 branch2 并对在那里扩展文件的代码进行一些更改（将“qwe”更改为“qwer”）。但是，在工作时，我还在基本代码（“1234”）中发现了一些错误并修复了它们（将“1234”更改为“12345”）。现在我的 HEAD 位于 branch2 的工作目录具有以下内容

现在我需要提交这个，我的目标是

我担心，如果我只是将其提交给 branch2，然后将单独重新应用 1234->12345 更改到 branch1 并提交，这将产生我正在寻找的结果，但 Git 会将其识别为两个独立且完全独立的提交，并且当我将来要经历类似的过程时（例如，branch1 中的 12345->123456，然后是 branch1->branch2 合并），我会在那个地方发生冲突。所以我的解决方案是使用交互式暂存仅将 qwe->qwer 更改提交到 branch2。然后 stash 剩余的更改（否则不允许切换回 branch1），切换到另一个分支，应用 stash，将 1234->12345 提交到 branch1，最后合并 branch1->branch2。

但是，这确实起到了作用，因为我对 Git 还比较陌生，所以我不太确定我是否以正确的方式以最好的方式使用了这些东西。请让我知道以上是否有意义，如果没有，请告诉我更好的方法。

出于某种原因，当苍蝇发生合并冲突时，看起来 git cherry-pick 会拉入其他提交。这些在我们使用时会消失，git mergetool但会阻止我们手动编辑合并冲突的文件。

有谁知道为什么会这样？

为了说明我的意思，让我们使用一个带有单个文件的全新 git 1.7.4 存储库foo：

让我们在这一点上创建一个名为bar. 回到 master，让我们在单独的提交中添加三个更改到这个文件。

提交 1：

提交 2：

提交 3：

由于最后一次提交很重要，因此我们决定将其拉回分支bar并git cherry-pick <commit>在该分支上。

不幸的是，这会在 file 中产生一个有趣的合并冲突foo：

请注意，这git mergetool似乎做了正确的事情并产生了这个：

为什么合并冲突的文件包含我们试图挑选的那个之前的提交？

首先，我宁愿不签入生成的文件，但我的经理坚持。因此，鉴于这些限制，我想创建一个反复无常的“合并模式”，它将始终在我的工作存储库中名为“生成”的所有目录中获取“他们的文件”。我已经阅读了hgrc 文档和相关帖子，我认为它应该是这样的：

这被放置在我的根 .hg/hgrc 文件中。当我运行带有合并冲突的 hg update 时，这就是我得到的：

所以我修改了“合并模式”看起来像这样：

这就是我得到的：

因此，我不再收到“找不到内部合并工具：其他”警告，但它仍在尝试合并生成的文件。

关于如何让它发挥作用的任何想法？

补充笔记：

1. 我们正在使用 Mercurial 版本 1.7.5，因为我们在使用新版本和子存储库时遇到了问题。
2. 我正在使用子存储库，所以这是我的主存储库的结构：

我有一个脚本在构建服务器上以非交互模式运行一些 Mercurial 命令。.hgtags其中一个命令合并了两个分支，并且由于构建脚本的设置方式，在合并期间文件中始终存在冲突。

如何强制 Mercurial 始终.hgtags使用两个文件的更改合并文件，首先是一个文件，然后是另一个文件？

例如，如果我要合并的文件是

和

我希望结果是

我猜我需要一个自定义合并工具。什么工具提供这个功能？

我还是 eGit 新手。我试图弄清楚如何让 eGit 使用我的副本解决合并冲突，没有任何变化。我指的是 eGit Wiki 上的注释：

http://wiki.eclipse.org/EGit/User_Guide#Possible_merge_results

但是，当我添加副本以解决冲突时，eGit 仍然在文件“<<<<<<< HEAD”、“=======”、“>>>>>>>> 中留下差异标记”。文档说使用合并工具后要添加：

编辑工作树版本，直到您满意为止 Team > 添加合并资源以将冲突标记为已解决 通过 Team > Commit 提交合并提交

但是，在我使用我的副本解决冲突后，它仍然会在文件中留下差异标记，这实际上不会导致任何更改，因此不需要保存。我的问题是如何让 eGit 接受、添加和提交我的副本而不在文件中留下差异标记？这些标记会在最终提交时消失吗？

我正在寻找一种工具，它将具有冲突标记的文件拆分为两个单独的文件。有什么东西可以做到这一点吗？

我有一个在 TFS 中启动的项目，然后转移到 Git。不幸的是，将它移至 Git 的人只是签入了当前文件，而不是使用 git-tfs。我试图在我使用 git-tfs 从 TFS 提取的提交之上重新调整他在 Git 中的新提交。

为此，我只是将他的提交重新设置在 git-tfs 提交之上。（我意识到这会弄乱远程 Git 分支，但我们是一个小团队，没关系。我也尝试过樱桃采摘，但我遇到了同样的问题。）

我遇到的问题是一组看起来像这样的冲突：

看来这是添加这些文件的 TFS 端的提交与添加它们的 Git 端的提交之间的冲突（因为 Git 存储库一开始是空的）。

合乎逻辑的事情可能是跳过这个提交，但是其中有几个文件（比如说几百个中有十个）是新的。当然，这些不会引起冲突。

为什么 Git 不能自己弄清楚这两个文件是相同的？即使我--ignore-whitespace在 rebase 时使用，Git 仍然会显示数十个类似的文件，这些文件似乎是相同的。我不知道如何解决这个问题。

我正在使用git-rerere它的预期目的，随着这些分支的发展逐渐记录两个分支（主分支和主题分支）之间的冲突解决方案，而不会创建不必要的合并提交。但是，即使在阅读了 git-rerere 联机帮助页之后，我也不清楚 rerere 何时实际记录了我的冲突解决方案。我检测和解决新合并冲突的标准工作流程是git merge master从主题分支开始，解决冲突，然后暂存所有文件并使用 提交合并git commit -m "Finished test merge"，然后使用 撤消合并git reset --hard HEAD^，只留下由git-rerere.

然而，这似乎有点愚蠢。创建提交然后撤消它只是为了记录解决方案？阅读手册页后git-rerere，我仍然不清楚它何时记录我的决议。仅暂存冲突文件是否足够，或者我是否真的需要在解决冲突后创建合并提交，就像我一直在做的那样？