从概念上，git merge和git rebase都是用来解决同样的问题，即合并两个branch的修改。
Both of these commands are designed to integrate changes from one branch into another branch—they just do it in very different ways.
merge
git merge dev:
Git 会自动根据两个分支的共同祖先commit 和两个分支的最新提交即进行一个三方合并，然后将合并中修改的内容生成一个新的 commit.
rebase
如果是在 master 分支上git rebase deve：Git 会从两个分支的共同祖先开始提取 master 分支（当前所在分支）上的修改，再将 master 分支指向 deve 的最新提交（目标分支）处，然后将刚刚提取的修改依次应用到这个最新提交后面。操作会舍弃 master 分支上提取的 commit，同时不会像 merge 一样生成一个合并修改内容的 commit，相当于把 master 分支（当前所在分支）上的修改在 deve 分支（目标分支）上原样复制了一遍.且新commit的hash code不同。
(串行)
总结：选择 merge 还是 rebase？
merge 是一个合并操作，会将两个分支的修改合并在一起，默认操作的情况下会提交合并中修改的内容
merge 的提交历史忠实地记录了实际发生过什么，关注点在真实的提交历史上面
rebase 并没有进行合并操作，只是提取了当前分支的修改，将其复制在了目标分支的最新提交后面
rebase 的提交历史反映了项目过程中发生了什么，关注点在开发过程上面
merge 与 rebase 都是非常强大的分支整合命令，没有优劣之分，使用哪一个应由项目和团队的开发需求决定
merge 和 rebase 还有很多强大的选项，可以使用git help 查看
最后：一些注意点
使用 merge 时应考虑是采用--no-ff默认操作，生成一个对回顾提交历史并不友好的合并记录，还是采用--ff-only方式
rebase 操作会丢弃当前分支已提交的 commit，故不要在已经 push 到远程，和其他人正在协作开发的分支上执行 rebase 操作
与远程仓库同步时，使用 pull 命令默认进行了git fetch + git merge --no-ff两个操作，可以通过加上--rebase命令将 fetch 后的 merge 操作改为 rebase 操作，或者仅仅 'git fetch remoteName',然后才思考采取哪种整合策略git merge(or rebase) origin/master
开发与 commit 时注意自己此时在哪个分支上。
Summary
If you would prefer a clean, linear history free of unnecessary merge commits, you should reach for git rebase instead of git merge when integrating changes from another branch.
On the other hand, if you want to preserve the complete history of your project and avoid the risk of re-writing public commits, you can stick with git merge.
参考：
http://www.jianshu.com/p/c17472d704a0
https://www.atlassian.com/git/tutorials/merging-vs-rebasing
