Question

我正在尝试将一个大主题分支合并到主服务器中，但我想要一个单独的提交来显示冲突解决方案是如何发生的。目标是让一个提交显示“这些文件冲突，他们如何冲突”，下一个提交将显示“这就是解决冲突的方式”。即第一次提交将包含冲突标记。

这样做的原因是主要分支已经过审查和测试，主分支也是如此。在合并中，我们只想查看需要一些工作的部分（冲突和其他合并工作）。

这就是我现在正在做的事情：

git checkout master
git checkout -b merge-from-topic
git merge topic

要记录有冲突的文件，我使用临时文件：

git diff --name-only --diff-filter=U >conflicts.txt

首先，我只是将带有冲突标记的文件添加到提交中：

xargs git add <conflicts.txt
git commit

然后我创建另一个分支（用于审查目的），我想在其中进行冲突解决：

git checkout -b resolve-merge-from-topic

要恢复冲突，我试过

xargs git reset HEAD^ -- <conflicts.txt

然后 git mergetool 表示虽然我工作树中的文件有冲突标记，但没有文件需要合并。

如何恢复conflict.txt中列出的文件，以便我可以在其上使用 git mergetool ？

我也对其他获得“单独提交解决冲突”效果的方式持开放态度。

Answer 1

git merge会留下冲突标记。

然后（通常）调用git mergetool（使用您偏好的--tool来解决冲突。大多数情况下，这将导致分阶段更改。 您想要更改（例如，使用git reset）。

现在单独提交“原始”合并，然后git add . && git commit -m 'resolutions'或git commit -am 'resolutions'添加冲突解决方案。

请注意，这会在合并边界修订版中留下“破损”版本。

分步骤：

git checkout -b be_merged       # start a temp branch for the merge (safety)

git merge --no-commit diverge   # initiate merge from a diverged branch
git status                      # shows conflicts
git mergetool                   # resolve them as always
git status                      # shows resolutions as staged
git reset                       # unstage the changes
git status                      # shows unstaged changes (good!)
git commit -m 'merge, conflicts pending'   # commit the merge
git commit -am 'conflicts resolved'        # commit the resolutions

Answer 2

如果你真的坚持要获得合并历史记录，那么最好的办法是使用git-imerge

AFAIK git imerge为您提供选择如果合并历史记录应该保留

REF：

http://softwareswirl.blogspot.de/2013/05/git-imerge-practical-introduction.html

作者博客的一篇文章：

git merge痛苦


你需要解决一个混乱很多的大冲突   合并双方的变化。（解决重大冲突很难！）

合并是全有或全无：

没有办法保存部分完成的合并，所以

您无法记录进度。

您暂时无法切换到其他分支。

如果您犯了错误，则无法仅还原部分合并。

如果你无法解决整个冲突，除了重新开始之外没有什么可做的。



无法测试部分完成的合并 - 在冲突完全解决之前，代码甚至无法构建。



与同事合并很难合作。

这可能正是您首先需要提交冲突的原因。

另一方面，不同的观点：

合并更改应尽可能保持在普通项目中尽可能小为什么会这样说，合并触及存储库中的所有文件将使您在将来真正感到痛苦。好像你要将你的分支与一些主要分支合并，假设你在生产分支上工作，而发布是从发布分支完成的，分支维护者将会只是尝试用他的分支来重新分支你的分支。

现在，如果你有一个触及该地方所有文件的提交，这将是一个读取不好的东西，因为合并最有可能发生冲突（主要的一个，可能是你所做的冲突提交）所以维护者将有两个选择：

自己合并
拒绝合并，让你做脏事

维护者更倾向于选择后者，因为对他来说这更容易。

因此，您将花费更多时间来解决冲突，而不是做一些富有成效的工作。

注意：

第二个视角仅适用于具有简单范围的要素主题。合并具有更大跨度的特征主题时，最好使用imerge并保留历史记录，这样您就可以进行较小的提交，并且不会感到痛苦。

Answer 3

这是一个非常糟糕的主意。您希望始终拥有稳定的代码库。你为什么要在一个冲突的状态下推送代码。

如果您想了解如何解决冲突，请对文件执行差异并查看其历史记录。

使用git merge单独提交冲突解决方案

3 个答案: