Git：压缩合并后反向合并

Question

我的团队正在使用类似 Gitflow 的工作流程，但最近从 develop 到 master 的发布合并是无意中作为壁球合并完成的。当时，我们没有发出任何警报，并认为下次我们会做对的，但后来我们不得不对该版本进行热修复。现在，我们需要将该修补程序重新合并到develop，这与master 不同。我们遇到了一些冲突，其中一些是合法的，但其中大部分是由于 git 认为 master 上的 squash-merge 提交代表它自己对更改的单独提交，而不是来自 develop 的合并而产生的噪音。

图表可能有助于说明问题：

 A ---------- D -- G (master)
  \
   \- B -- C -- E -- F (develop)

在这种情况下，D 是 B 和 C 的 squash-merge 的结果（而不是我们通常所做的常规合并）。请注意，git diff C D 返回空 - 即它们的内容相同。

现在，我想将master 合并到develop；由于E、F 和G 之间的合法重叠，我预计会出现一些冲突（因此我不能简单地说“使用我们的”或“使用他们的”）。但我在B、C 和D 中的所有内容基本上都发生了冲突，大概是因为 git 将D （可以理解）视为它自己的提交，在master 上的一个单独的提交链中从 A 开始.

长话短说，我希望的是“相对于这两个相同的提交（C 和 D）合并”而不是“相对于 A 合并”。有点像rebase --onto，但我猜是为了合并。

FWIW，我知道我可以手动解决冲突；我只是好奇是否有一种方法可以跳过在创建 D 时执行 squash-merge 而不是常规合并而引入的所有垃圾冲突。

Answer 1

更新 - 我忘记了有关其工作原理的重要信息；固定。

---

现在我假设进行历史重写（以及随后的清理）并不是一个实际的解决方案......

在这种特定情况下，最简单的技巧是在合并期间使用git replace。如果不是因为 C 和 D 具有相同的内容，这不会起作用。

在克隆中你可以说

git replace --graft <E> <D>

（其中<E> 和<D> 是解析为相应提交的表达式；在上面的示例中，这可能是git replace --graft develop^ master^）。这会创建一个“看起来像”E 的新提交 E'，但它的父级是 D。然后它使用E' 作为E 的替代品——所以当一个操作将git 引导到E 时，它仍然会看到Es 提交ID，但它会从E' 获取有关该提交的其余信息.身体上你有

                E'
               /
 A ---------- D -- G (master)
  \
   \- B -- C -- E (REPLACE:E')
                 \
                  F (develop)

那么你

git chekcout develop
git merge master

（或者可能是git merge hotfix-branch，但您没有在图表中显示，所以我们将使用简化示例）...现在merge 命令“看到”

A ---------- D -- G (master)
              \
               (E|E') -- F (develop)

所以它使用D 作为合并基础。因为C和D的内容是一样的，所以计算出来的合并结果是应该的。结果“看起来像”

A ---------- D ------------ G (master)
              \              \
               (E|E') -- F -- M (develop)

这是真的

                E'
               /
 A ---------- D ------ G (master)
  \                     \
   \                F -- M (develop)
    \              /
     \- B -- C -- E (REPLACE:E')

现在D..M 周围的历史“看起来很有趣”，这是这样做的缺点（而不是用真正的合并替换 D 的历史更正）。 M 是一个边界“邪恶合并”，但由于默认合并无论如何都会发生冲突（并且由于计算结果是冲突的“自然”解决方案），这并不可怕。

完成此操作后，您不再需要更换。 master 和 develop 之间的未来合并无论如何都会将 G 视为合并基础，因此之前的混乱并不重要。