- 主题:git merge和git rebase到底有啥区别?
其实 我关心从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.*
最合适的方式你放着不用,非要和 merge 较劲干嘛
rebase 不加 onto 那么就会变成 a->b->c->d->e->f->h->i
【 在 iStudy (爱学习) 的大作中提到: 】
: 其实 我关心从C到A,只同步C上的两个节点,最简单怎么操作?
: cherrypick最保险。
: 如果用rebase或者merge,步骤是什呢?
: ...................
--
修改:cybereagle FROM 220.200.25.*
FROM 220.200.25.*
git checout A
git merge C呢?
【 在 cybereagle (2/3的沉默@XMUCSD) 的大作中提到: 】
: 最合适的方式你放着不用,非要和 merge 较劲干嘛
: rebase 不加 onto 那么就会变成 a->b->c->d->f->h->i
--
FROM 139.224.253.*
你猜f会不会过来?
【 在 iStudy (爱学习) 的大作中提到: 】
: git checout A
: git merge C呢?
--
FROM 220.200.25.*
哈哈,这是我想知道的点,很久不用了,忘记了。
我猜会!如果我猜不会,我就不发这个帖子了,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.*
会
我眼花了
【 在 iStudy (爱学习) 的大作中提到: 】
: 不加onto 为什么e不会过来?
--
FROM 220.200.25.*
C合回A排除病态的需求后,从A切出一个新分支,common_bug_fix,称为D
D cherry pick C 的最后两次提交
A merge D
B rebase A
A merge B
日常开发,公共feature提交到公共分支,master,一般叫基线产品,也有叫中台的。
A 和B都能release,说明只是两个不同的产品线。
任何分支只合并从自己切出去的分支。永远只有两步:
次分支rebase主
主分支合并次
【 在 iStudy 的大作中提到: 】
: A,B都是可以release的
: 一些客户需要B上的feature,所以B也是要release的
: C是B分支上的客户报的bug,所以从B拉的bufix分支C
: ...................
--
FROM 113.137.164.*