Git合并策略-我们的用例

Question

我读了Pro Git书，并遇到以下use case of ours merge strategy：

  

通常在以后进行合并时使Git认为分支已经被合并通常很有用。例如，假设您从一个发行分支分支出来，并且已经对其进行了一些工作，那么您将需要在某个时候合并回您的主分支。同时，master上的一些错误修正需要回移植到您的发行分支中。您可以将bugfix分支合并到release分支中，也可以将merge -s ours的同一分支合并到您的master分支中（即使已存在此修复程序），因此当您以后再次合并release分支时，bugfix不会产生冲突。

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

让我们假设bugfix分支在单个文件中引入了1行更改。如果我已经在master分支上拥有此更改的行，则合并到包含相同更改的行的release分支中（由于与bugfix分支合并）不会引起任何冲突。

Answer 1

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

  

即使已存在修复程序

应该真的不在括号内。

所描述的情况是master中已经存在的一个错误修复程序，并且还存在于某些尚未合并到master的错误修复程序分支中。也许它被选为“太重要”的修复程序，对于维持其理智的历史而言？

无论如何，本段试图说明一种情况，您希望-s ours合并，现在我考虑了一下，我认为这是一个很好的例证：混淆，可能是由于一些漫不经心的Cherrypicks / squash合并而产生的结果，您只是想弄清楚如何更正记录，而又不中断此后发生的所有工作，因为您现在拥有的只是谎言：

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

因此，这里真正发生的事情是，一个不加思索的白痴，可能是我，将bugfix压合并到master上，因为这最简单。您遇到了这个问题，只是勉强阻止了我，打电话给我，让我选择了想念的想法，因为尽管我在这里滥用南瓜的做法非常糟糕，但是，有一个简单的解决方案：

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

生成历史记录图最好绘制为

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

这不是很正确，但与您将不得不强行推销我本应建立的历史一样，它与正确性非常接近。 Bx的提交消息应该读为“ -s是我们的修正记录了在B'处的南瓜合并的错误修正的合并”或类似内容。

现在，人类和机器都可以轻松了解合并历史的发生和原因：从release到master的后续合并将不会尝试应用B1中的更改和B2，因为它发现它们已经合并。