大约 4 分钟
Git Merge 、Rebase
git merge a
会找到两个分支的共同祖先、以及两个分支各自最新的提交，然后进行三方合并，并且在对合并中修改的内容形成一个新的commit
git rebase a
也就是变基，即把当前分支的祖先更改为a分支最新的提交。此时a为基分支，当前分支为**待变基分支。**git会从两个分支的祖先开始提取待变基分支的提交，然后把当前分支指针指向基分支最新提交，然后应用刚才提取到的修改（即：以a为基底合并当前分支代码）
rebase与merge的功能都是合并代码
现在假设有两个分支：dev 和 dev-pqs （dev-pqs是模拟各个开发人员的开发分支）
dev-pqs基于dev分支拉出，然后进行了 A B两个提交
然后dev分支分支有个新的提交 M（比如是其他开发人员合并上去的），如下图
把dev-pqs的代码合并到dev
merge
- 切换当前分支为dev-pqs
- 执行git merge dev （后续应该再切换到dev分支，然后把dev-pqs合并到dev，这个步骤就省略了，因为如果有冲突，冲突已经在1、2两个步骤解决掉了，也可以直接执行这两个步骤）
结果如下：
rebase
- 切换当前分支为 dev-pqs
- 执行 git rebase dev （后续应该再切换到dev分支，然后把dev-pqs合并到dev，这个步骤就省略了，因为如果有冲突，冲突已经在1、2两个步骤解决掉了，也可以直接执行这两个步骤）
rebase前，dev-pqs分支的祖先是dev那个提交，rebase后，祖先就更改为dev的最新提交，也就是m那次提交。如下图：
区别
- merge操作通常会生成一个新的commit，已提交的commit的版本号不会发生编号
- merge后分支的祖先信息不会丢失
- merge操作后的结果能提现出时间线
- rebase操作后分支祖先信息会丢失，如上图看不出dev-pqs的祖先
- rebase同时会更改commit的版本号，比如上面的A、B两个提交的版本号就发生了变化。A: 11e75—>c78c B: 68b0—>106d
- rebase操作后并不是按照时间线排列（当然可以根据提交时间判断）
merge还是rebase?
根据上面的区别，再根据公司、项目实际情况选择使用即可
git pull
git pull 等效于 git fetch + git merge
git pull -r 等效于 git pull -rebase 又等效于 git fetch + git rebase
idea的rebase操作
点击红框”rebase dev-pqs onto dev” 就相当于在执行 git rebase dev，一样的效果。 这个”onto”感觉很形象，有点体现出以dev为基底的感觉
idea设置
系统推荐
- 常见问题
- synchronized原理深度剖析
- Btrace入门
- 弱引用示例
- Spring框架源码关键点
- MongoDB高可用
- 测试两台服务器间的网速
- JVM异常处理
- 推荐几个适用小工具
- SpringCloud总体认识
- 免费 API 每日提供摸鱼日报，自动返回无水印图片，适用于公众号和小程序
- Linux
- 随机毒鸡汤：暖男燃烧完所有的暖，就成了渣男。