在我们把代码push之前，首先要做的是查看远程其他分支是否已经有更新的代码，先将代码进行合并；这时候你有2个选择：git merge 或者是git rebase；
两者的区别和不同：
git merge 操作合并分支会让两个分支的每一次提交都按照提交时间（并不是push时间）排序，并且会将两个分支的最新一次commit点进行合并成一个新的commit，最终的分支树呈现非整条线性直线的形式
merge 会把要合并分支和你当前的commit 合并在一起，形成一个新的 commit 提交
git rebase操作实际上是将当前执行rebase分支的所有基于原分支提交点之后的commit打散成一个一个的patch，并重新生成一个新的commit hash值，再次基于原分支目前最新的commit点上进行提交，并不根据两个分支上实际的每次提交的时间点排序，rebase完成后，切到基分支进行合并另一个分支时也不会生成一个新的commit点，可以保持整个分支树的完美线性
rebase会把你当前分支的 commit 放到基本你想要的分支的最后面,所以叫变基。就好像你从原基分支又重新拉出来这个分支一样。
注意:
- 不要在公共分支使用rebase
- 本地和远端对应同一条分支,优先使用rebase,而不是merge
为什么不要再公共分支使用rebase?**
因为往后放的这些 commit 都是新的,这样其他从这个公共分支拉出去的人，都需要再 rebase,相当于你 rebase 东西进来，就都是新的 commit 了
merge和rebase实际上只是用的场景不一样
更通俗的解释一波.
自己开发的分支：比如featureA,一直在做,然后某一天，你想把主线的修改合到你的分支上,做一次集成,这种情况就用rebase比较好.把其他的分支的提交放到前面，把你的提交都放在最后，可以保证顺序；
如果用merge，脑袋上顶着一笔merge的8,你如果想回退你分支上的某个提交就很麻烦；
当然并不完美,rebase的话,本来我的分支是从3拉出来的,rebase完了之后,就不知道我当时是从哪儿拉出来的我的开发分支
主分支： rebase其他分支的修改,是不是要是别人想看主分支上有什么历史,他看到的就不是完整的历史课,这个历史已经被你篡改了，所以此时应该用merger，好在一般主分支的合并都是通过Pull Request，且需要通过代码审查后才会执行自动的merge；
常用指令
- 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
经过上面的分析：我们大概能提炼出一个规范：
- 开发人员，从dev分支迁出自己的开发分支，进行开发并进行提交；
- 开发人员，在开发完成该功能分支时，执行一次git rebase -I dev进行一次变基；
- 变基过程中，一样会存在冲突的情况，解决冲突后执行 git add . 命令，并进行继续的变基git rebase —continue
- 直到整个变基过程完成；
- 如果中间遇到任何问题：执行git rebase –abort 放弃这次的变基操作；
需要注意的是：自己的分支不要偏离主线太远，差异过大的话，冲突和要处理的差异就越多；需要随时和主线进行同步
、
若有收获，就点个赞吧
0 人点赞
