Git：仅合并分支所做的更改

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

根据我们对项目的特殊需求，上述情况发生的情况非常普遍。我们有一些提交的主/开发分支。然后我们得到一个错误报告，并开始修复错误分支（提交上面的C和D）。同时在开发分支中发生更多的提交。接下来我们被告知我们需要为客户创建一个发布版本，其中不能包含上面提交的B，E和F提交的更改，但它应该包含错误修复。Git：仅合并分支所做的更改

因此，在更改B应用之前，我们分支了dev，但是在这个版本分支中修复bug的最佳方法是什么？如果我执行分支合并，它将包含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.这真的是一件坏事吗？这会导致什么问题？是否有更好的方式将错误修复分支中的更改导入发布分支？

来源

2011-07-06 DaveJohnston

使用樱桃挑选没有真正的危险，特别是如果您不打算将release分支合并到master。

一般来说，您可以通过将错误修复基于您要合并修补程序的所有分支中包含的提交中的错误修复来防止出现问题。在开发git本身时，通过将所有错误修复合并到maint分支（即仅接收修复的当前稳定系列），然后定期将其合并到master中来实现。这样，解决方案无处不在，并且合并是理智的。

来源

2011-07-06 11:27:42

如果我将发布分支合并回主版本，会有什么危险？在我所做的图中，改变H最终需要被应用回主分支。 – DaveJohnston

好吧，如果您不将错误修复分支合并到主服务器中，则没有问题。如果你这样做了，你可能会得到比你更多的冲突（如果两个分支以相同的方式修改代码的这些部分，并在其上添加一些不同的更改）。 “危险”是多余的，真的......这意味着你必须手动修复一堆冲突，并且这两个提交会在你的历史记录中显示两次（使用不同的提交ID）。 –

This文章建议，而不是合并两个分支，你会rebase他们在哪里git只会rebase非重复提交。

但在挑肥拣瘦的代替，你可能会考虑只重订的分支：

rebase --onto release B bug

其中release是发布分支和bug是错误的分支。

然后你得到类似

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

但是，这将意味着，当你想将被应用的bug修复掌握，你将需要合并的bug与掌握，从而导致所有的版本也将改变被添加到主。

这取决于你决定什么最适合你。

请注意，您不应该将已经为pushed的分支重新分配给其他分支，因为它会为他们创建一个混乱。

来源

2011-07-06 11:20:40 Ikke

通过它的外观，所有这些提交被推送到远程回购。在这种情况下，不宜采用rebase。 – Sailesh

在我看到此评论之前添加了该部分。 – Ikke

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

在合并的情况下，你会因为重复的承诺
请参阅“Git cherry pick and datamodel integrity”
忽略函数依赖得到冲突。
请参阅“How to merge a specific commit in git”。

你的情况：

没有必要合并回去。
如果您确定C和D不是基于B中介绍的代码，请在需要它们的地方挑选它们。

来源

2012-11-19 11:35:49 VonC

Git：仅合并分支所做的更改

回答

相关问题