合并时藏匿

Question

我有一个问题刚刚提出我的同事,我想知道这个问题最好的git工作流程.

假设我们有两个分支A和B.现在我们foo.c在A和B中都改变了一些文件(),所以当我们将B合并到A时,我们得到合并冲突.现在让我们说一些开发人员搞砸了并离开了分支A一个破碎的状态,错误也在foo.c中,但在一个未合并的行中.

我看到了处理这种情况的一些可能性:

1. 存储挂起的合并,修复A上的问题,提交然后再次应用合并.但是在这一点上,我不确定如何为foo.c所做的更改处理正确的合并策略.破碎的部分可能会影响我所做的一些事情,因此我没有看到解决冲突的明确方法.

2. 撤消合并,修复A上的问题,然后重做整个合并.但是我可能已经解决了其他冲突,所以这可能会失去很多工作.

3. 拿--theirs/ - 我们的文件版本,完成合并,修改更改,樱桃选择已经丢失的更改.然而,我会有两次变化.

4. 其他一些解决方案,我无法想到.

所有这些解决方案让我感到有些不满意.根据我的惯常经验,我可能会选择1,但我绝对不确定.

你会如何处理这种情况？

Answer 1

您无法隐藏未提交的合并。选项 1 立即从列表中删除。

就干净的历史记录而言，选项 2 的变体是最好的。Git 具有记住冲突解决方案的能力；它只是默认禁用。您可以启用它：git config --global rerere.enabled。根据需要解决冲突。通常你会提交合并，Git 会记录你解决冲突的方式。由于您实际上还不想提交合并，因此您可以运行git rerere以立即记录冲突解决方案而无需提交。（或者，如果您继续并提交合并，则可以git reset --hard HEAD^重置为之前的状态。冲突解决方案仍会被记住。）

然后，您可以修复分支 A 中的问题，并重做合并。Git 会重新使用记录的冲突重新解决。它仍然会被标记为未合并，以便您有机会git add在未合并的路径上运行并提交合并之前检查它并确保它做了正确的事情。

事实上，我不清楚选项 3。为什么你必须挑选？听起来好像foo.c只在分支 A 中被破坏，这是您要合并到的分支，因此所有这些都将在分支 A 内。所需的历史记录是错误修复，然后是合并；如果您继续合并然后解决问题，那么您只是交换了两次提交的顺序。无论如何，没有必要进行重复提交 - 如果您澄清的话，我可以帮助避免这种情况！