merge rebase

merge 和 rebase都是用来合并分支的

分支

分支：协调的时候提高开发效率。不同的功能不同的分支，互不影响。开发完后都合并到develop提测

合并

每个人开发好后,把各自的代码放到一起叫合并

冲突

合并的时候，不同的分支修改相同的位置。

“<<<<<<<” 表示冲突代码开始

“=======” 表示2个分支冲突代码分隔符

“>>>>>>>" 表示冲突代码的结束

merge 和 rebase的区别

1. rabase会把你要合并的�分支放到当前分支的后面，叫变基

例如：你从master分支拉一个feature分支，然后commit了几次，这个时候你同事也从master分支来一个功能分支，开发完成合并到master分支了。这个时候你用rebase master合并到master分支上，就会把你提交的记录放到，你同事的提交记录后面

merge 会把公共的分支和你当前的commit合并到一起，形成一个新的commit提交

image.png

2. 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

git 分支命名规范