1、Merge命令
merge命令会保留所有提交的历史时间。每个人对代码的提交是各式各样的，尽管这些时间对于程序本身并没有任何意义，但是merge的命令初衷就是为了保留这些时间不被修改。
这样也就形成了以merge时间为基准的网状历史结构。每个分支上都会继续保留各自的代码记录, 主分支上只保留merge的历史记录，子分支随时都有可能被删除。
子分子删除以后，你能够看到的记录也就是，merge（合并）某branch（分支）到某branch（分支）上了。这个历史记录描述基本上是没有意义的。
（也就是子分支的历史提交，在该分支删除后，不能被保留。回退或者charry-pick的时候，选择性变少了。）
2、Rebase命令
rebase命令会始终把你最新的修改放到最前头，你会更有信心保证你的代码运行畅通无阻，通过你自己的测试以后，你就可以放心的把代码合并到主的branch里面了。
这里值得一提的是，rebase通常是发生在自己的个人branch上的。它的基础就是现有的主branch，这样做的好处就是保证每个人的代码都可以运行在当前最新的主branch的代码上。
3、总结
rebase命令好处：
-
rebase命令是没有合并操作的，它只是将当前分支所做的修改，重放到了目标分支的最后一次提交上。 -
rebase命令最大的好处是你的项目历史会非常整洁 ，最后的项目历史呈现出完美的线性。你可以从项目终点到起点浏览而不需要任何的 fork。
rebase命令坏处：
-
rebase过程中，一个commit出现冲突，下一个commit也极有可能出现冲突，一次rebase操作可能要解决多次冲突，同时合并的历史脉络（冲突）被物理消灭了。 - 安全性，如果你违反了 rebase 黄金法则，重写项目历史可能会给你的协作工作流带来灾难性的影响。
- 可跟踪性，
rebase操作不会有合并提交中附带的信息，你看不到 feature（特征） 分支中，并入了上游的哪些更改。
merge命令：
-
merge是一个合并操作，提交历史记录会出现分叉，显得不是那么简洁。 -
merge命令合并结果不好看，一堆线交错，但合并有冲突的话，只要解一次就行了。
4、个人推荐
情况一
如果你想拥有一套稳定的，健壮的代码，永远要使用rebase。不为别的，就为了可以给你提供一套清晰的代码历史记录。
rebase操作永远不会导致多个历史分支进行交织。它永远都是一条线，纯洁而又干脆，轻轻爽爽的，从不拖泥带水。
相反的，merge操作会给你一套乱七八糟的代码历史。当你看到这样的代码历史的时候，那个画风我相信对你一定很熟悉。想着那个画风感觉到一切都好无助，有个词儿比较合适，叫做欲仙欲死。
情况二
但是从中国特色的敏捷开发情况（疯狂改方案，迭代）：
如果只是在本地修改一两个commit，然后马上提交到主要分支上，跑完所有unit test（单元测试），integration test（集成测试），regression test（回归测试）等，直接发布。也就是continuous integration（持续集成）的理想状态，那么rebase操作是极好的。保证了主线分支的线性，且万一出事了可以准确的revert（回退）。
那么如上所述：
- 本地开发，如果经常需要
rollback回滚，就用rebase操作。 - 本地开发，灵活创建分支，也可以使用merge合并分支，方便解决冲突。
5、注意点
如果你违反了 rebase 黄金法则，重写项目历史可能会给你的协作工作流带来灾难性的影响。
rebase 的黄金法则：永远不要在公共分支上使用rebase操作。
在你运行 git rebase 命令之前，一定要问问你自己「有没有别人正在这个分支上工作？」。如果答案是肯定的，那就不能进行rebase 操作。
一般来说，执行rebase命令的分支都是自己的本地分支，千万不要在与其他人共享的远程分支上使用rebase操作。
这不难理解，远程分支上的代码可能已经被其他人克隆到本地了，如果通过rebase操作修改了远程分支的提交历史，这样其他人每次拉取代码到本地时，就都需要进行复杂的合并。
注意：git merge和git rebase的显著区别是，前者不会修改git的提交记录，而后者会！
提示：与远程仓库进行同步时，也可以执行命令
git pull --rebase origin master
参考：
