- 主题:git merge和git rebase到底有啥区别？
我说一个场景
A,B,C三个分支,A是主分支，相当于master
B从A拉出，C从B拉出，
现在
A->（a->b->c->d）四个节点
B->(b->e->f->g)
C->(f->h->i)
我
1.只把C的h,i合并到A，用rebase和merge 分别怎么做？ 不许用cherrypick等命令。
2.把B,C所有改动都合并到主分支A，用rebase和merge分别怎么做？
--
修改:iStudy FROM 139.224.253.*
FROM 139.224.253.*
你这个太乱了。
如果是我， 我肯定
1.C直接(merge还是rebase?)合并到A
2.在B上更新A啊（rebase还是merge?)，把A上的拉下来。。
如果B是feature分支，C是bugfix分支，你这种操作，是不是太麻烦了。
【 在 DoorWay (DooWay) 的大作中提到: 】
: 只把C，我的h,i合并到A，首先这是个病态的需求，因为h, i可能以来f，f可能依赖e，合不上。
: 如果确定h， i是独立的commit，不依赖 b c d e f，
: 1 c分支rebase B，生成b e f g h i 的历史
: ..................
--
FROM 139.224.253.*
A,B都是可以release的
一些客户需要B上的feature,所以B也是要release的
C是B分支上的客户报的bug，所以从B拉的bufix分支C
后来发现这个bug其实影响所有的客户。
那么，正确做法，从A拉出bugfix分支C，提交修复后，同步到所有feature分支。。。但我们已经从C拉出来了。。。所以从C合并到A才最省力！
【 ，在 DoorWay (DoorWay) 的大作中提到: 】
: A不应该知道C的存在。因为不是从C切出去的。
: 祝你开心
--
修改:iStudy FROM 139.224.253.*
FROM 139.224.253.*
其实 我关心从C到A,只同步C上的两个节点，最简单怎么操作？
cherrypick最保险。
如果用rebase或者merge，步骤是什呢？
最容易想到的操作；
1.checkout A
2.merge from C
这样操作会把本属于B分支改动，或者叫多余节点也merge到A了，是不是用rebase，才能满足我的要求。
第一回复人说应该用rebase onto A h i...感觉合我意。难道不加onto A h,i不行？
【 在 iStudy (爱学习) 的大作中提到: 】
: A,B都是可以release的
: 一些客户需要B上的feature,所以B也是要release的
: C是B分支上的客户报的bug，所以从B拉的bufix分支C
: ...................
--
修改:iStudy FROM 139.224.253.*
FROM 139.224.253.*
git checout A
git merge C呢？
【 在 cybereagle (2/3的沉默@XMUCSD) 的大作中提到: 】
: 最合适的方式你放着不用，非要和 merge 较劲干嘛
: rebase 不加 onto 那么就会变成 a->b->c->d->f->h->i
--
FROM 139.224.253.*
哈哈，这是我想知道的点，很久不用了，忘记了。
我猜会！如果我猜不会，我就不发这个帖子了,e会不会也合并过来呢？
【 在 cybereagle (2/3的沉默@XMUCSD) 的大作中提到: 】
: 你猜f会不会过来？
--
修改:iStudy FROM 139.224.253.*
FROM 139.224.253.*
不加onto 为什么e不会过来？
【 在 cybereagle (2/3的沉默@XMUCSD) 的大作中提到: 】
: 最合适的方式你放着不用，非要和 merge 较劲干嘛
: rebase 不加 onto 那么就会变成 a->b->c->d->f->h->i
--
FROM 139.224.253.*