1、git合并
作为一个版本控制工具，git提供了两种合并代码的方式，merge（合并）和 rebase（变基）两种方法在合并上面并没有什么区别，但是在总提交分支表中会有相应的变化
- merge（合并）：会将两个分支代码产生冲突的地方直接合并进来，成为一个新分支
- rebase（变基）：会将分支迁出的第一个提交合并到主分支上，再合并所有的副分支提交
如图所示，蓝色部分为开发主分支，黄色部分为迁出的副分支，那么他们在合并过程中是不同的。merge会将两个分支最新的提交进行合并。而rebase则会将主分支最新和副分支最古老提交进行合并，再将副分支的所有提交合并起来。
那么我们再分支提交总览中，看看merge合并的结果。
可以看见，如果我们使用merge合并的方式，会出现密密麻麻的各种分支合并情况，但rebase不同，他就会合并成为一条线上。
那么既然merge合并看着密密麻麻，我们均使用rebase变基行不行？
rebase的意义：rebase的最大好处并不是消除merge，而是避免merge的交织。简要来说，就是在merge进被合分支（如master）之前，最好将自己的分支给rebase到最新的被合分支（如master）上，然后用pull request创建merge请求。我们需要合理利用 rebase 和 merge 来避免 git 历史提交里的 无意义的‘交织’
什么是无意义的交织？
先来了解一个场景，当我上线某个大版本的时候，他集成了非常多的功能，此时上线出现了bug，假如我能够快速定位到某个分支出了问题，那么我们回滚那个分支即可。
此时我们可以回想亦喜爱 rebase 和 merge 解决分支冲突的区别，如果是使用 rebase 解决冲突，那么我们并不能快速定位并回滚到那个分支出现的问题，反而， merge 解决冲突就能够快速定位。因此，有意义的交织就是能够快速定位并回滚的提交的交织 ，无意义的交织就是分支提交并不会出现什么风险而回滚的情况，使用 merge 解决冲突会造成不必要的眼花缭乱的分支图。
总结
rebase 和 merge 在解决问题上并没有很大的区别，他们唯一的区别就是在分支图上， merge 能够快速定位交织但是分支图比较混乱，而 rebase 交织图是线性的但出现问题的时候不能快速回滚版本。因此我们建议在合并大版本和大的业务变更代码等风险大的改动的时候，使用 merge合并 解决问题，而一些改动风险非常小的冲突，使用 rebase变基 解决