Question

  G---H             // Release Branch
 /
/
A---B---E---F---    // master
    \
     \
      C---D---     // bug fix branch

根据我们对项目的特殊需求，上述情况很常见。我们的master / dev分支有一些提交。然后我们得到一个错误报告并开始修复bug分支（上面提交C和D）。在此期间，dev分支中会发生更多提交。接下来我们被告知我们需要为客户创建一个版本，该版本不能包含上面提交的B，E和F引入的更改，但它应该包含错误修复。

所以我们在更改B之前应用了dev，但是将错误修复到这个版本分支的最佳方法是什么？如果我执行分支的合并，它将包括在B中做出的我不想要的更改。我可以执行提交C和D的樱桃选择，但我读到樱桃采摘并不总是一个好主意based on this answer，基本上因为我的回购将会是这样的：

  G---H---C'---D'--- // Release Branch
 /
/
A---B---E---F---     // master
    \
     \
      C---D---       // bug fix branch

所以C'和D'显示为全新的提交，其中不同的sha-1 ID为C和D.这真的是一件坏事吗？这会导致什么问题？有没有更好的方法将错误修复分支的更改发送到发布分支？

Answer 1

This文章建议不要合并两个分支，你可以将它们重新定义为git只会重复非重复提交。

但是，除了采摘樱桃之外，您可能会考虑重新选择分支：

rebase --onto release B bug

其中release是发布分支，bug是bug分支。

然后你得到像

这样的东西

         C'---D' //Bug branch      
        /
       /
  G---H  // Release Branch
 /    
/ 
A---B---E---F---     // master

但这意味着当您希望将错误修复应用于master时，您需要将bug与master合并，这会导致发行版中的所有更改也被添加到master中。

由您来决定什么最适合您。

请注意，您不应该将pushed的分支重新绑定到其他分支，因为这会给它们造成混乱。

Answer 2

使用cherry-pick并不存在真正的危险，特别是如果您不打算将release分支合并到master。

通常，您可以通过对要将合并修补程序合并到的所有分支中包含的提交进行错误修复来防止此类问题。在git本身的开发中，这是通过将所有错误修复合并到maint分支（即仅接收修复的当前稳定系列），然后定期将其合并到master中来实现的。这样，修复无处不在，合并是理智的。

Answer 3

注意：如上所述，这里采摘樱桃是可以接受的它的主要缺点是：

在合并的情况下，由于重复提交，您会遇到冲突请参阅“Git cherry pick and datamodel integrity”
忽略功能依赖请参阅“How to merge a specific commit in git”。

在你的情况下：

无需合并。
如果您确定C且D不是基于B中引入的代码，则可以在任何需要的地方挑选它们。

Answer 4

创建一个补丁文件，其中包含来自bugfix分支的唯一内容。然后将该补丁文件应用于release分支。

示例：

> git checkout bugfix_branch
> git diff B HEAD > unique_changes.patch /* where "B" is the point where bugfix_branch split from dev */
> git checkout release_branch
> git apply unique_changes.patch

瞧！现在，您的发行版分支中的bugfix分支只有唯一的更改。请注意，format-patch倾向于更优雅地处理文件已被移动或删除的情况，因此您可能需要处理生成补丁的实际过程，但是这种方法应该可以使您接近。

Git：仅合并在分支上进行的更改

4 个答案: