面试官：git pull是哪两个指令的组合？ 点击小卡片，参与粉丝专属福利！！之前校招面试时遇到这样一个问题，git pull是哪两个指令的组合？ 当时是一脸懵的说不知道啦。 那现在为什么又捡起来说呢？因为我搞懂了??。 剧透一下，本文的主旨与 合并代码 有关??：当时刚开始编程，全是一个人自嗨，完全没有合并代码这一场景??。于是并没有深究，工作后合并代码是常有的事，不得不去了解一下了。 先说结果：git pull是两个指令的组合：git fetch和git merge。从git fetch开始FETCH_HEAD讲git fetch之前，还需要先了解一个东西，就是.git文件夹下的一个文件，FETCH_HEAD。 image.png可以通过 git log -p FETCH_HEAD 和 open .get/FETCH_HEAD 这两个指令去查看FETCH_HEAD（初始时没有这个文件，会报错，可以先用git fetch创建）。下面演示一下： 下图是没有该文件：下图是有该文件：git log -p FETCH_HEAD查看 image.pngopen .get/FETCH_HEAD查看 image.png大致内容就是，目前有两个分支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，提示已经是最新的。 image.png这肯定是错误的操作啦！大家都知道，合并代码前要拉取最新的代码，如果你不了解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 fetchgit merge origin/master这样减少了checkout的操作。 可以相较最开始演示的图里看一下，git fetch后，FETCH_HEAD中记录的master分支的commit id变了。 git fetch前?? image.pnggit fetch后?? image.png所以，我们合并时要拉最新的代码其实就是为了更新FETCH_HEAD。通过git fetch就可以在不切换分支的情况下去更新FETCH_HEAD。 一次因为git pull展开的学习，over ～ ^?_?^ 2023.10.10补充大佬提出『「新版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 image.png使用--global选项将配置应用到全局范围，这意味着该配置将适用于所有的Git仓库。如果只想在特定仓库中使用特定策略，可以在该仓库的根目录下运行上述命令，而不使用--global选项。 还需注意，即使配置了默认策略，仍然可以在每次执行git pull时使用--rebase或--no-rebase选项来覆盖默认行为。 例如，即使将git pull配置为使用merge策略，仍然可以运行git pull --rebase来使用rebase策略进行拉取。反之亦然。 2023.10.13补充评论区有大佬提出的，合并代码那一步可以直接git pull origin master，不必fetch再merge。?? (^_^) 如果文章对你有帮助的话欢迎「关注+点赞+收藏」 阅读原文