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

Dav*_*ton 20 git version-control merge branch git-branch

  G---H             // Release Branch
 /
/
A---B---E---F---    // master
    \
     \
      C---D---     // bug fix branch
Run Code Online (Sandbox Code Playgroud)

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

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

  G---H---C'---D'--- // Release Branch
 /
/
A---B---E---F---     // master
    \
     \
      C---D---       // bug fix branch
Run Code Online (Sandbox Code Playgroud)

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

Ikk*_*kke 10

条建议,以代替合并两个分支,你会重订他们在那里的git只会变基非重复提交.

但是,除了采摘樱桃之外,您可能会考虑重新调整分支:

rebase --onto release B bug
Run Code Online (Sandbox Code Playgroud)

release发布分支在哪里,bug是bug分支.

然后你得到类似的东西

         C'---D' //Bug branch      
        /
       /
  G---H  // Release Branch
 /    
/ 
A---B---E---F---     // master
Run Code Online (Sandbox Code Playgroud)

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

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

请注意,您不应该将已送到其他分支的分支重新绑定,因为它会为它们造成混乱.


Jan*_*ger 5

使用cherry-pick 并没有真正的危险,特别是如果您不打算将分支合并releasemaster.

一般来说,您可以通过将错误修复基于您想要将修复合并到的所有分支中包含的提交来进行修复。在 git 本身的开发中,这是通过将所有错误修复合并到分支maint(即仅接收修复的当前稳定系列)然后master定期合并来实现的。这样,修复就无处不在,合并也很正常。