写在开篇
对于很多同学来说，对于git工具的使用只是停留在最基础的几条命令或者是几个按钮上，对于普通的开发工作来说可能是够用了，但对于想高效的利用好git这个实战利器来说，显然是需要再精进提升的。
今天我们将从代码合并这个角度，为大家讲解git中merge与rebase的区别，使用场景等。
区别
初始场景
假设目前我们有两个分支，main和feature，同时两个分支的head指针都指向add ClassB这个提交节点上，如下图所示。
无分叉情况下合并
对于第一种情况，main分支新增一个提交，其head指针指向add ClassC提交节点上，而feature分支的仍然停留在add ClassB上。
此时我们希望在feature分支上将main分支上的最新提交合并过来，此时对于两个分支来说，它们是没有分叉的，merge默认会采用的策略是fast-forward，即快速将feature的head指针移动到add ClassC上。
有分叉情况下合并
对于下图，main和feature分支中出现了分叉的情况，如果想要将main中的提交合并到feature中，我们应该怎么做呢？
merge
对于之前没有了解过rebase的我们来说，我们通过merge来将main中提交的ClassC合并到feature来，我们会在ClassE节点后新增一个merge结点，放到自己的最后面，如下图所示。
而这个merge节点，它是main分支上更改的合并，即不管main分支上多少个提交节点，都会合并成一个节点。
rebase
但如果通过rebase合并后，feature分支的提交还是在最后，就好像从节点ClassC中拉出来的一样，此时相对于main分支没有分叉。
优缺点
上述两个例子很清晰的提现了merge和rebase的区别和作用，简单来说：
- merge保留了作品的完整历史记录，包括按时间顺序排列；对于回滚等操作也更有优势
- Rebase使提交变得整洁，不会产生嘈杂的提交
使用场景
merge
- 对于多个人开发同一个模块，很可能他的某个改动会导致你的功能出问题，如果出了问题，保留记录能便于后期排查问题
- main分支需要将开发完的子分支的内容合并进来，使用merge可以留有提交记录，出现问题方便后面排查问题
rebase
个人开发分支同步main最新提交应该使用rebase，该模块的内容更新和你功能无关，合并代码也不会影响你的功能，无需保留该记录
