面试官:git pull是哪两个指令的组合?😯

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

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

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

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

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


从git fetch开始

FETCH_HEAD

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

可以通过 git log -p FETCH_HEAD 和 open .get/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 ~

^ _ ^

相关推荐
原则猫7 小时前
UDP 到底怎么实现可靠的
前端
Java后端的Ai之路7 小时前
14、ReactJS - 路由(Router)
前端·react.js·状态模式
裕晟资质规划9 小时前
三类涉密资质延续时限差异分析:军工60日与集成印制3个月的边界
java·服务器·前端·网络·安全
ShineWinsu9 小时前
对于JavaScript:JavaScript基础语法的解析
开发语言·前端·javascript·面试·web·基础语法·循环
月夏9 小时前
Vue3 转 React:18 项对照表 + 5 个必踩的坑(附 7 天上手路线)
前端
广州华水科技9 小时前
单北斗GNSS位移监测系统的应用与维护解析
前端
梦曦i9 小时前
uni-storage 0.1.0 发布:TTL过期管理+多实例隔离
前端·storage·uni-app x
猫头_10 小时前
AI 流式传输工程指南:模型吐出半截 JSON,前端如何边收边渲染?
前端·javascript·llm
console.log('npc')11 小时前
第 1 章 项目概述与环境搭建
前端·人工智能·大模型
定栓11 小时前
Webpack迁到Vite第七节(二):全家桶移除 — Babel 全家桶深度分析
前端·webpack·node.js