git rebase 与 Git merge的区别

Git Merge

Git merge是git中的合并技术之一，其特点是分支上的提交日志是完整的。
例如，下图中master分支上有3个commit分别为1、2、3，而功能分支提交了A、B两个commit。如果执行merge操作，那么提交A、B将合并为4提交到master分支。

优点：commit完整，log日志详尽，有助于了解每次合并发生的时间和方式的完整历史
缺点：日志混乱，不是很人性化

Git Rebase

Git rebase与Git merge类似，都可以实现分支的一个合并操作，不同的是rebase合并后修改了日志。引入rebase操作的目的是解决merge操作过多导致的日志杂乱问题，rebase的操作日志看起来是线性的。
例如，下图中master分支上有3个commit分别为1、2、3，而功能分支提交了A、B两个commit。如果执行rebase操作，那么提交A、B将被修改为提交4、5合并到master的最后。

优点：日志是线性的，结构清晰
缺点：无法跟踪功能分支的提交时间和方式

什么时候使用Git Merge与Git Rebase

merge	rebase
用于合并分支	用于将一个分支的更改集成到另一个分支
日支完整	日志是线性的，不完整
功能分支的所有提交将合并为一个提交合并到master	所有提交完整的提交到master分支
目标分支为共享分支时使用merge	目标分支是私有分支时使用rebase

举例说明，如下图所示：

从Git Merge的结果图可以看出commit A、B来自功能分支，但在Git rebase中很难看出commit 4、5从何而来。因此，当我们的团队需要可以追溯每一个commit的详细提交记录（人、时间、log日志）时，使用merge比较合适。当功能分支只有很少的人参与开发，且不存在子分支时，我们可以使用rebase集成master的新功能。

Git Rebase和Git Merge如何搭配使用

假如我们有一个项目，它的master分支由commit 1、2、3和功能分支1、2组成，功能分支1上有commit A、B，功能分支2上有commit C、D。

假设开发人员A正在功能分支1上开发，为了试验代码他又创建了功能分支2，在其中做了一些修改，最终提交为commit C、D，这在平时开发中是很常见的。
现在他不想让其他人看到功能分支2，因为那是他的私有分支，没有必要存在。因此，它可以在功能分支2上对功能分支1做rebase操作。

接下来他可以将功能分支1合并到master上了。

以上是其他开发人员开到的最终日志的样子，他们只能看到功能分支1上的commit。