17

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

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

这是我目前正在做的事情：

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？

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

4

3 回答 3

3

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
于 2013-09-17T21:35:01.450 回答
2

如果您真的坚持要获取合并历史记录，那么最好的选择是使用 git-imerge

AFAIK git imerge 让您选择是否应该保留合并历史

参考：

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

来自作者博客的尝试：

git merge疼痛

  • 您需要解决一个大冲突，它混淆了合并双方的许多小更改。（解决大冲突很难！）
  • 合并是全有或全无：
    1. 没有办法保存部分完成的合并，所以
      • 你不能记录你的进步。
      • 您暂时无法切换到另一个分支。
      • 如果您犯了错误，则不能仅还原部分合并。
      • 如果你不能解决整个冲突，那就只能重新开始。
    2. 没有办法测试部分完成的合并——在冲突完全解决之前，代码甚至不会构建。
  • 与同事就合并进行协作是很困难的。

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

另一方面，另一种观点：

在一个微不足道的项目中，合并更改应尽可能少。为什么要说的是，涉及存储库中所有文件的合并将使您在未来感到非常痛苦。就好像您要将您的分支与某个主要分支合并，假设您在生产分支上工作，而发布是从发布分支完成的，分支维护者只会尝试用他的分支重新定位您的分支。

现在，如果您有一个涉及该位置所有文件的提交，这将是一个读取错误的东西，因为合并很可能会发生冲突（主要的，可能是您所做的冲突提交），因此维护者将拥有2个选项：

  1. 自己合并
  2. 拒绝合并，让你做脏活

维护者更有可能选择后者，因为这对他来说更容易。

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

笔记：

第二种观点仅适用于具有简单跨度的专题主题。当合并具有较大跨度的特征主题时，最好使用 imerge 并保留历史记录，这样您将有更小的提交并且 rebase 不会很痛苦。

于 2013-09-20T08:35:52.653 回答
1

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

如果您想查看冲突是如何解决的，请对文件进行比较并查看它的历史记录。

于 2013-09-19T14:40:12.753 回答