之前校招面试时遇到这样一个问题，git pull是哪两个指令的组合？

当时是一脸懵的说不知道啦。

那现在为什么又捡起来说呢？因为我搞懂了。

剧透一下，本文的主旨与 合并代码 有关：当时刚开始编程，全是一个人自嗨，完全没有合并代码这一场景。于是并没有深究，工作后合并代码是常有的事，不得不去了解一下了。

先说结果：git pull是两个指令的组合：git fetch和git merge。

从git fetch开始

FETCH_HEAD

讲git fetch之前，还需要先了解一个东西，就是.git文件夹下的一个文件，FETCH_HEAD。

可以通过 git log -p FETCH_HEAD 和 open .git/FETCH_HEAD 这两个指令去查看FETCH_HEAD（初始时没有这个文件，会报错，可以先用git fetch创建）。下面演示一下：

下图是没有该文件：

下图是有该文件：

git log -p FETCH_HEAD查看

open .get/FETCH_HEAD查看

大致内容就是，目前有两个分支master分支和test-*分支，以及这两个分支最新的commit ID（正常项目内，这个文件内容很多，但你不需要记住这个文件的内容，看懂这个简单例子就好）

这个文件是干啥的？

FETCH_HEAD文件记录了远程仓库中的分支名称、最新的commit id以及提交的作者等相关信息。

但它不是随着远程仓库实时变更的，是保存在我们本地，那就需要我们手动去更新。

当执行git fetch命令时，它会从远程仓库获取最新的提交信息，并将这些信息存储在本地FETCH_HEAD中。

再说git merge

说到git merge，逃不开的必须提到git rebase，这俩是合并代码中的重要大将。

git merge

• 作用: 将两个分支的更改合并为一个新的合并提交。
• 使用场景:
• 当你想要将一个分支的更改 合并 到另一个分支时，特别是在多人协作的项目中。
• 当你想要保留完整的分支历史记录，以及合并的详细信息。
• 优点:
• 保留了完整的分支历史记录，可以清晰地看到合并的路径和详细信息。
• 合并提交是一个新的提交，不会改变原有提交的内容和历史。
• 缺点:
• 合并后的提交历史可能会变得复杂，包含大量的合并提交。

git rebase

• 作用: 将一个分支的更改基于另一个分支的最新提交进行重新应用。
• 使用场景:
• 当你想要将一个分支的更改 应用 到另一个分支上，同时保持一个线性的提交历史。
• 当你想要保持清晰、整洁的提交历史，避免过多的合并提交。
• 优点:
• 产生一个线性的提交历史，使得提交历史更加整洁和易于理解。
• 可以减少合并提交的数量，使得提交历史更加简洁。
• 缺点:
• 可能会改变原有提交的内容和历史。

总结一下

git merge 适用于多人协作的项目，保留完整的分支历史记录。

git rebase 适用于保持整洁的提交历史和线性的提交记录。

选择使用哪个命令取决于具体的项目需求和工作流程。

实际应用

铺垫了这么多后，接下来就是我实际想讲的，工作中时常用到的，如果你也有下面提到的小问题，这篇文章就有小小的大用。

git fetch和git merge以及相关扩展介绍完毕，讲下面的内容已经够用了。

有同学可能会有疑问，git pull都是两个指令的集合了，为什么要拆开讲，为什么需要学？难道拉代码时，还要先git fetch再git merge？那不是耽误事嘛～

是的，拉代码时不必拆开来如此麻烦，但是另一个场景更需要拆开来执行，就是合并代码。

开始合并

还是test-*分支和master分支，现在已经有另一个用户在master分支提交了一条新的commit，我们需要将master分支合并到test-*分支，如果我们现在直接去执行git merge，提示已经是最新的。

这肯定是错误的操作啦！大家都知道，合并代码前要拉取最新的代码，如果你不了解git fetch，你可能会先切换到master分支，再git pull，然后切回test-*分支，然后再git merge master，这里的步骤如下：

git checkout master

git pull

git checkout test-*

git merge master

这样没有不对，只是更繁琐而已（这就是上面指的小问题）。

讲FETCH_HEAD文件的目的，是为了告知在合并代码时，实际是根据FETCH_HEAD文件中记录的commit id去合并对应的版本，所以我们只需要更新FETCH_HEAD文件就行，那么我们的合并流程就可以简化成以下两步：

git fetch

git merge origin/master

这样减少了checkout的操作。

可以相较最开始演示的图里看一下，git fetch后，FETCH_HEAD中记录的master分支的commit id变了。

git fetch前

git fetch后

所以，我们合并时要拉最新的代码其实就是为了更新FETCH_HEAD。通过git fetch就可以在不切换分支的情况下去更新FETCH_HEAD。

一次因为git pull展开的学习，over ～

^?_?^

补充

有大佬提出『新版git pull第二个指令不一定是merge了，得看config怎么设置的』，这里做进步一解释^?_?^

在Git中，从版本1.7.10开始，可以配置git pull使用merge或rebase策略。

要配置git pull的默认策略，可以使用git config命令。

• 将git pull配置为使用rebase策略：
• git config --global pull.rebase true
• 将git pull配置为使用merge策略：
• git config --global pull.rebase false

是否配置，可以通过以下命令查看：git config --global -l

使用--global选项将配置应用到全局范围，这意味着该配置将适用于所有的Git仓库。如果只想在特定仓库中使用特定策略，可以在该仓库的根目录下运行上述命令，而不使用--global选项。

还需注意，即使配置了默认策略，仍然可以在每次执行git pull时使用--rebase或--no-rebase选项来覆盖默认行为。

例如，即使将git pull配置为使用merge策略，仍然可以运行git pull --rebase来使用rebase策略进行拉取。反之亦然。

补充

有大佬提出的，合并代码那一步可以直接 git pull origin master ，不必fetch再merge。

作者：aomyh
链接：https://juejin.cn/post/7283691376649633828