我正在尝试将一个大主题分支合并到主服务器中,但我想要一个单独的提交来显示冲突解决方案是如何发生的.目标是让一个提交显示"这些文件冲突以及它们如何冲突",下一个提交将显示"这就是解决冲突的方式".即第一次提交将包含冲突标记.
原因是大主题分支已经过审查和测试,主分支也是如此.在合并中,我们只想查看需要一些工作的部分(冲突和其他合并工作).
这是我到目前为止所做的:
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？
我也对其他获得"单独提交冲突解决"效果的方式持开放态度.
假设我们有一个develop分支和一个feature分支。该develop分支非常频繁地收到来自数十名开发人员的许多更新。它经常比分支走得更远feature。
有一次，from 的合并develop导致feature了 300 个低级冲突。这些冲突涉及代码库的许多不同领域，并且没有一个开发人员熟悉所有这些领域。因此，任何单个开发人员都很难解决其本地计算机上的每个冲突，以便推送逻辑正确、无冲突的项目版本。
我知道最好的解决办法是避免这种情况。然而，排除——由于组织功能失调、既成事实等原因，这种情况存在——如何最好地利用git来解脱呢？
我对 git 的理解是，不可能提交任何处于冲突状态的东西；通过分阶段，您表明它并不冲突。然而，这似乎要求任何和所有冲突都成为进行合并的人的不共享、不协作的责任。这是不可取的，因为解决冲突是一项艰巨的任务，各个部分最好由不同的人处理。
我想到了两种可能的出路。然而，两者听起来都不是很好。首先，我考虑尝试解决我能解决的冲突，仅提交这些解决方案，然后让其他开发人员处理他们适合的部分。然而，据我所知，git 不支持任何类型的临时合并提交，并且实际上不会让您开始合并并随后提交，除非您在本地处理add每个冲突的文件，从而将其标记为已解决。我相信这个答案支持了我的担忧。
这让我想到了第二个想法，那就是仅仅修复我能修复的部分，并提交其余的部分，包括冲突标记。幸运的是，我能够解决所有高级冲突（文件重命名/删除等），但如果我没有解决，这些仍然是一个问题。抛开feature分支将处于非编译状态不谈，我担心 git 将不再认为这些文件存在冲突；这意味着我们必须依赖 IDE 和其他工具来检测 git 冲突标记。
我的偏好是仅提交实际已解决的文件，允许其他开发人员拉取它们，而未实际解决的文件仍向他们指示为冲突。
我还注意到有一个--no-commit可用的选项git merge，我想知道这是否是可行的方法，因为我认为它允许我只提交我实际审查过、理解和解决的文件，同时保留剩余的文件本地未提交的冲突。
是否有更有效的策略来使用 git 将合并的责任分配给多个开发人员？