[git] git pull vs git pull --rebase_git pull --rebase origin

1、git pull

通常在更新local repo时，会使用 git pull 将origin repo的更新拉取到本地，从而保证 local repo 和 origin repo 的一致性。

首先，git pull == git fetch + git merge

git fetch：从 origin repo 获取 local repo 需要更新的数据

git merge：将刚才git fetch获取的数据合并到 local repo

显而易见，git pull 带有默认参数 --merge；

2、git pull --rebase

rebase 意为变基，它同 merge 一样，常用于合并分支修改，但不同的是，merge会保留所有的历史记录，不会对其调整，而 rebase 则会将历史记录调整为一条顺畅的历史记录线，何意？请看如下对比：

2-1 git pull 操作现象

① 远程仓库有四个提交，但是本地仓库只有三个，远程仓库新于本地仓库

origin repo:

local repo:

② 此时，local repo落后于 origin repo 一个提交，但这时，在 local repo 提交了一笔新的code，此时 local repo为

local repo:

③ 之后在 local repo 执行git pull，会发生什么呢？请看下图：

local repo:

在 local repo 的 log 记录里，会看见出了我们之前提交的 commit 5，还新生成了一个 commit 6，并且这个 commit 6 的提交信息 通常为 “Merge branch xxxxxx” 。

这是因为 local repo 执行 git pull 时， origin repo 的 log 是和 local repo 不一致的，在拉取新的记录的时候，就会进行自动合并历史记录的操作，并生成一个新的提交，记录此次commit

其实它真正的历史记录是这样的：

从以上我们可以知道，使用 git pull 会保留完整的历史记录，并且不会改变 log 历史。这是 git pull 的优势

那如果我们一直使用 git pull 会出现什么呢？

可以看见，当记录越多的时候，记录会越来越大，并且看起来不太直观，这对于团队合作的比较大的工程是不适用的！

2-2 git pull --rebase 操作现象

同理，① ②两步与 git pull 状态一致：

origin repo:

local repo:

③ 此时，在 local repo 执行 git pull --rebase ，结果如下：

从结果可以看出，这个操作不会重新生成 commit，并且在 commit 3和 commit 5之间插入了commit4；

git pull --rebase 会让历史记录成为一条干净的线性记录，但是，它会改变 local 的 log 记录。很明显，这对于团队合作的工程来说是比较合适的。