Git:只合并分支上所做的更改 [英] Git: merge only the changes made on the branch

查看:192
本文介绍了Git:只合并分支上所做的更改的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

  G --- H //发布分支​​
/
/
A --- B --- E --- F-- - // master
\
\
C --- D --- //错误修复分支

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



因此,我们在开始应用变更B之前就已经开始分支了,但是在这个版本分支中修复bug的最好方法是什么?如果我执行分支合并,它将包含B中所做的更改,这是我不想要的。我可以执行提交C和D的樱桃选择,但我读了樱桃采摘并不总是一个好主意基于这个答案,主要是因为我的回购看起来像这样:

  G --- H --- C'--- D'--- //发布分支​​
/
/
A --- B --- E --- F --- // master
\
\
C --- D --- //错误修复分支


$ b因此C'和D'表现为与C和D不同的sha-1 ID的全新提交。这真的是一件坏事?这会导致什么问题?有没有更好的方式从错误修复分支进入发布分支?

解决方案

没有真正的危险使用樱桃选择,特别是如果你不打算将版本分支合并到 master 中。 >

一般而言,您可以通过修复所有想要合并修补程序的分支中提交的错误修复来防止类似问题。在开发git本身时,通过将所有错误修复合并到 maint 分支(即仅接收修复的当前稳定系列),然后将其合并到 master 定期。这样,解决方案无处不在,合并合理。


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

Based on our particular needs for our project, it is quite common for the above scenario to occur. We have our master/dev branch with some commits. Then we get a bug report and start fixing that on the bug branch (commits C and D above). More commits happen in the dev branch in the meantime. Next we are told we need to create a release for a customer which cannot include the changes introduced by commits B, E and F above, but it should include the bug fix.

So we branch off of dev before change B was ever applied, but what is the best way to get the bug fix into this release branch too? If I perform a merge of the branch it will include the change that was made in B which I don't want. I could perform a cherry-pick of commits C and D but I read that cherry picking is not always a good idea based on this answer basically because my repo would then look like:

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

So C' and D' appear as completely new commits with different sha-1 IDs as C and D. Is this really a bad thing? What problems can this lead to? Is there a better way of getting the changes from the bug fix branch into the release branch?

解决方案

There is no real danger in using cherry-pick, especially if you don't plan on ever merging the release branch into master.

In general, you can prevent problems like these by basing bug fixes on commits that are included in all branches you want to merge the fix into. In the development of git itself, that is achieved by merging all bug fixes into the maint branch (i.e. current stable series which only receives fixes) and then merging that into master periodically. That way, the fix is everywhere and the merges are sane.

这篇关于Git:只合并分支上所做的更改的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆