git - Git 合并策略——我们的用例

Question

我阅读了 Pro Git 的书，发现了我们合并策略的以下 用例：

这通常很有用，可以基本上诱使 Git 在稍后进行合并时认为分支已经合并。例如，假设您分支了一个发布分支，并且已经完成了一些工作，您希望在某个时候合并回您的主分支。同时，需要将 master 上的一些错误修复移植到您的发布分支中。您可以将错误修复分支合并到发布分支，也可以merge -s ours将同一分支合并到您的主分支（即使修复已经存在），因此当您稍后再次合并发布分支时，错误修复不会发生冲突。

有人可以解释一下在这种情况下主分支和发布分支之间可能发生的冲突吗？为什么我需要假装我已经将 bugfix 分支合并到 master ？

假设错误修复分支在单个文件中引入了 1 行更改。如果我在 master 分支上已经有了这个更改的行，那么在包含相同更改行的发布分支中合并（因为与 bugfix 分支合并）不会导致任何冲突。

标签： git

Answer 1

散文有点难以解压，我认为有效载荷子句：

即使修复已经存在

真的不应该在括号中。

所描述的情况是一个已经存在的错误修复，master并且还存在于一些尚未合并到master. 也许它被挑选为“太重要”而无法保持理智历史的修补程序？

不管怎样，这一段试图说明一种你想要-s ours合并的情况，现在我想起来了，我认为这是一个很好的例子：困惑，可能是一些粗心的cherrypicks/squash合并的结果，您只是想弄清楚如何在不破坏此后发生的所有工作的情况下更正记录，因为您现在得到的是谎言：

  B1..B2         bugfix
 /
*...B'...        master
 \
  `--...         release

bugfix所以这里真正发生的是，一些粗心大意的白痴，可能是我，master因为它最简单或其他什么而被压扁了。你遇到了这个，几乎没有阻止自己打电话给我，并给我选择了你脑海中的想法，因为即使我在这里严重滥用了 squash 合并，嘿，有一个简单的解决方案：

git checkout release; git merge bugfix
git checkout master; git merge -s ours bugfix

生成历史图可能最好绘制为

  ,--...*...o     release
 /         /
*--B1--B2-'       bugfix
 \         \
  `...B'...-Bx    master

这并不完全正确，但与您不必强行推动我应该创造的历史一样接近正确。提交消息Bx可能应该是“-s ours merge of bugfix record the squash merge at B'”或类似的内容。

现在人类和机器都可以很容易地看到发生了什么以及历史被合并的原因：随后的从releaseto合并master不会尝试将更改应用到B1并且B2因为它看到它们已经被合并。