git 合并的两种方式

先假设有 master（公共分支） 和 dev 分支

merge

直接合并

git checkout master
git merge dev

把两个分支的最新快照以及二者最近的共同提交点进行三方合并，合并的结果是生成一个新的快照（并提交）。

pull 操作合并

git pull 操作等于：git fetch + git merge FETCH_HEAD(origin/master)

git pull origin master

rebase

我们始终在合并某一个分支（如dev）的代码时，先将目标分支（如master）变基到待合并的分支（dev）上 。然后再使用merge将待合并分支（dev）合并到目标分支（master）

变基到目标分支（master），也可以说将master分支合并到dev

git checkout dev
git rebase master

或

git rebase master dev

它的原理是首先找到这两个分支的最近共同提交点，然后对比当前分支相对于该共同提交点的历次提交，提取相应的修改并存为临时文件。然后将当前分支指向目标分支的最新提交点, 最后将之前另存为临时文件的修改依序应用到当前分支的后面。

合并dev分支到master

git checkout master
git merge dev

pull 操作合并

git pull --rebase 操作等于：git fetch + git rebase FETCH_HEAD(origin/master)
后面加上 --rebase 表示：在 fetch 远程代码后，使用 rebase 做合并操作。

git pull origin master --rebase # git fetch + git rebase FETCH_HEAD 

变基 vs. 合并

到底哪种方式更好。 在回答这个问题之前，让我们退后一步，想讨论一下提交历史到底意味着什么。

有一种观点认为，仓库的提交历史即是 记录实际发生过什么。 它是针对历史的文档，本身就有价值，不能乱改。 从这个角度看来，改变提交历史是一种亵渎，你使用 谎言 掩盖了实际发生过的事情。 如果由合并产生的提交历史是一团糟怎么办？ 既然事实就是如此，那么这些痕迹就应该被保留下来，让后人能够查阅。

另一种观点则正好相反，他们认为提交历史是 项目过程中发生的事。 没人会出版一本书的第一版草稿，软件维护手册也是需要反复修订才能方便使用。 持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事，怎么方便后来的读者就怎么写。

现在，让我们回到之前的问题上来，到底合并还是变基好？希望你能明白，这并没有一个简单的答案。 Git 是一个非常强大的工具，它允许你对提交历史做许多事情，但每个团队、每个项目对此的需求并不相同。 既然你已经分别学习了两者的用法，相信你能够根据实际情况作出明智的选择。

总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史， 从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。