git - merge 时存储

Question

我的一位同事刚刚提出一个问题，我想知道解决这个问题的最佳 git 工作流程。

假设我们有两个分支 A 和 B。现在我们更改了 A 和 B 中的一些文件 (foo.c)，因此当我们将 B merge 到 A 中时会发生 merge 冲突。现在假设一些开发人员搞砸了，使分支 A 处于损坏状态，错误也在 foo.c 中，但在未 merge 的行中。

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

1. stash 挂起的 merge ，修复 A 上的问题，提交，然后再次应用 merge 。但是，此时我不确定如何针对两者对 foo.c 所做的更改处理正确的 merge 策略。损坏的部分可能会影响我所做的一些事情，因此我没有看到解决冲突的明确方法。

2. 撤消 merge ，修复 A 上的问题，然后重做整个 merge 。但是，我可能已经解决了其他冲突，因此这可能会减少很多工作。

3. 获取 --theirs/--ours 版本的文件，进行 merge ，修复更改，挑选丢失的更改。不过，我会进行两次更改。

4. 一些我想不到的其他解决方案。

所有这些解决方案都让我觉得有点不尽如人意。根据我通常的经验，我可能会选择 1，但我对此完全不确定。

你会如何处理这种情况？

Answer 1

您无法 stash 未提交的 merge 。选项 1 立即从列表中移除。

就清理历史而言，选项 2 的变体是最好的。 Git 有能力记住冲突解决方案；默认情况下它只是被禁用。您可以启用它:git config --global rerere.enabled。根据需要解决冲突。通常你会提交 merge ，Git 会记录你解决冲突的方式。由于您实际上还不想提交 merge ，因此您可以运行 git rerere 立即记录冲突解决方案而不提交。 (或者，如果您继续并提交 merge ，您可以只 git reset --hard HEAD^，重置到它之前。冲突解决仍然会被记住。)

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

实际上，我不清楚选项 3。你为什么要 cherry-pick ？听起来 foo.c 只在分支 A 中损坏，这是您要 merge 到的分支，所以所有这些都在分支 A 中。所需的历史记录是错误修复，然后是 merge ；如果您改为继续 merge 然后解决问题，那么您只是在切换两个提交的顺序。在任何情况下，都没有必要重复提交 - 如果您澄清，我可以帮助避免这种情况!