merge rebase
merge 和 rebase都是用来合并分支的
分支
分支：协调的时候提高开发效率。不同的功能不同的分支，互不影响。开发完后都合并到develop提测
合并
每个人开发好后,把各自的代码放到一起叫合并
冲突
合并的时候，不同的分支修改相同的位置。
“<<<<<<<” 表示冲突代码开始
“=======” 表示2个分支冲突代码分隔符
“>>>>>>>" 表示冲突代码的结束
merge 和 rebase的区别
- rabase会把你要合并的�分支放到当前分支的后面，叫变基
例如：你从master分支拉一个feature分支，然后commit了几次，这个时候你同事也从master分支来一个功能分支，开发完成合并到master分支了。这个时候你用rebase master合并到master分支上，就会把你提交的记录放到，你同事的提交记录后面
merge 会把公共的分支和你当前的commit合并到一起，形成一个新的commit提交
image.png
- merge不会保留merger分支的commit的提交记录
image.png
注意
- 不要在公共的分支使用rebase
- 本地分支和远程对应同一条分支，优先使用rebase
为什么不要再公共分支使用rebase?
因为往后放的这些 commit 都是新的,这样其他从这个公共分支拉出去的人，都需要再 rebase,相当于你 rebase 东西进来，就都是新的 commit 了
- 1-2-3 是现在的分支状态
- 这个时候从原来的master ,checkout出来一个prod分支
- 然后master提交了4.5，prod提交了6.7
- 这个时候master分支状态就是1-2-3-4-5，prod状态变成1-2-3-6-7
- 如果在prod上用rebase master ,prod分支状态就成了1-2-3-4-5-6-7
- 如果是merge
1-2-3-6-7-8
........ |4-5| - 会出来一个8，这个8的提交就是把4-5合进来的提交
merge和rebase实际上只是用的场景不一样
更通俗的解释一波.
比如rebase,你自己开发分支一直在做,然后某一天，你想把主线的修改合到你的分支上,做一次集成,这种情况就用rebase比较好.把你的提交都放在主线修改的头上
如果用merge，脑袋上顶着一笔merge的8,你如果想回退你分支上的某个提交就很麻烦,还有一个重要的问题,rebase的话,本来我的分支是从3拉出来的,rebase完了之后,就不知道我当时是从哪儿拉出来的我的开发分支
同样的,如果你在主分支上用rebase, rebase其他分支的修改,是不是要是别人想看主分支上有什么历史,他看到的就不是完整的历史课,这个历史已经被你篡改了
常用指令
git rebase -I dev 可以将dev分支合并到当前分支
这里的”-i“是指交互模式。就是说你可以干预rebase这个事务的过程，包括设置commit message，暂停commit等等。
git rebase –abort 放弃一次合并
合并多次commit操作:
1 git rebase -i dev
2 修改最后几次commit记录中的pick 为squash
3 保存退出,弹出修改文件,修改commit记录再次保存退出(删除多余的change-id 只保留一个)
4 git add .
5 git rebase --continue
