- 主题: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.
git rebase —onto A f i
2.
git checkout A
git merge B C
我只会这个，别的不会
【 在 iStudy 的大作中提到: 】
: 我说一个场景
: 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分别怎么做？
: --
:
发自「今日水木 on 鸿蒙」
--
修改:adu FROM 73.231.198.*
FROM 73.231.198.*
只把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 的历史
2 向B发merge request。不过看你这野路子，直接切换到B分之，merge C即可。del C
3 重点，在B上rebase -i，调整下 h i的顺序，生成 (h i) b e f g的历史
4 次重点，切换到master上，merge B:i ，只合并到某次提交。
A不应该知道C的存在。
语义上，注意不是技术上，merge表示feature分之开发完成，主分支接纳
rebase只是个技术手段，一个场景，次分支自己解决合并冲突，然后通知主分支合并；二是日常拉取远端时，git pull —rebase，不想造成无所谓的合并。核心还是1，自己解决远端的变化。
【 在 iStudy 的大作中提到: 】
: 我说一个场景
: A,B,C三个分支,A是主分支，相当于master
: B从A拉出，C从B拉出，
: ...................
--
FROM 61.185.159.*
rebase是修改历史，相当于把你的commits重新在更新后的base上重做一遍
个人的pull request应该尽可能rebase而不是merge，这是对reviewer的尊重
【 在 iStudy (爱学习) 的大作中提到: 】
: 我说一个场景
: A,B,C三个分支,A是主分支，相当于master
: B从A拉出，C从B拉出，
: ...................
--
FROM 27.91.71.*
2.把B,C所有改动都合并到主分支A，用rebase和merge分别怎么做？
——固定的模式，1 次分支rebase on 主分支，2 主分支merge 次分支。
※ 修改:·DoorWay 于 Mar 20 08:36:06 2022 修改本文·[FROM: 61.185.159.*]
※ 来源:·水木社区
http://m.mysmth.net·[FROM: 61.185.159.*]
修改:DoorWay FROM 61.185.159.*
FROM 61.185.159.*
merge 会产生 merge commit，特征是该 commit 有两个 parents
rebase 不会产生 merge commit
正常情况下，master/production 等重要分支除了 admin 以外是没有写权限的，只能通过提交 PR 才能 merge 代码进来，没人有权限直接去 master 上做 rebase 这种操作（实际上是没有 git push origin master 的权限，本地改没人管的着）。
至于工作分支提 PR 有 conflicts 的话，个人习惯是 rebase，历史看起来比较干净
【 在 iStudy (爱学习) 的大作中提到: 】
: 我说一个场景
: A,B,C三个分支,A是主分支，相当于master
: B从A拉出，C从B拉出，
: ...................
--
修改:eGust FROM 203.211.107.*
FROM 203.211.107.*
merge是合并，rebase是嫁接。就这。
【 在 iStudy 的大作中提到: 】
:
: 我说一个场景
: A,B,C三个分支,A是主分支，相当于master
: B从A拉出，C从B拉出，
:
#发自zSMTH@RVL-AL09
--
FROM 61.148.245.*
你这个太乱了。
如果是我， 我肯定
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不应该知道C的存在。因为不是从C切出去的。
祝你开心。
【 在 iStudy 的大作中提到: 】
: 你这个太乱了。
: 如果是我， 我肯定
: 1.C直接(merge还是rebase?)合并到A
: ...................
--
FROM 113.137.164.*
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.*