git pull 初级思考

[godkun]

核心

我们看下面这张图：

分析上图，我们可以知道，git pull 等价于 ：

git pull = git fetch + git merge  
git pull = git fetch + git rebase
git pull = git pull --rebase

既然可以等价多个，那就要有一个默认等价了，那就是 git pull 默认等价于 git fetch && git merge 。

你可能要问了，为什么会选择上面这个默认等价呢 ？

其实我们分析一下可以知道，git 版本控制中的合并只有两种方式，一种是 merge , 一种是 rebase 。

从初级角度我们可以这样理解

git merge 符合用 git 进行版本控制的核心思想，因为 merge 操作不会去掉任何一个 commit ，这和使用 commitId 来表示版本库代码不谋而合，所以默认使用 merge 操作 。不要改动提交 push 的commit

git rebase 命令会对以前的 commitId 进行变更，同时让 commit 时间线在一条时间线上。比如有的人喜欢 rebase ， 就像是在说我想把我的修改放在其他人的修改之上。

rebase 也是好用的

事实上, 使用 rebase 来 pull 是一个很常见的工作流, 甚至为了他专门有个 config :

git config --global branch.autosetuprebase always

运行上面的命令后，git pull 就不再是 git fetch && git merge 了，而是 git fetch && git rebase 。

我个人感受

其实，我个人觉得，用 merge 也好，用 rebase 也好，都不重要，重要的是你要保证你的操作是安全可靠的。你觉得用某一个，已经影响到你的正常工作了，比如你 CR 的时候，发现一堆 merge 记录，你肯定是比较烦的，这个时候你就可以去推一下 rebase ，因为 merge 有多种策略，它自己会自动选择最合适的策略，有的策略会在 merge 后生成一个 commitId ，而 rebase 就不会生成新的 commitId 。所以还是要看个人的情况，灵活运用才是王道。