前端八股整理（工程化 01）｜Git 常见命令、rebase/merge、pull/fetch 与前端性能优化

前端八股整理（工程化 01）｜Git 常见命令、rebase/merge、pull/fetch 与前端性能优化

1.git的常见命令?git rebase和git merge的区别?git pull和git fetch的区别,暂存区,工作区和远端仓库有什么区别?

git 的常用命令?

常见的 Git 命令我平时主要会用这些：

• git clone：把远程仓库克隆到本地
• git pull：拉取远程最新代码并合并到本地当前分支
• git add：把修改添加到暂存区
• git commit：把暂存区内容提交到本地仓库
• git push：把本地提交推送到远程仓库
• git switch：切换分支，也可以配合 -c 创建并切换到新分支
• git branch：查看或管理本地分支
• git merge：把某个分支的改动合并到当前分支
• git rebase：把当前分支基于另一分支最新提交重新整理提交历史，让历史更线性

如果日常开发里，我还会用：

• git status：查看当前工作区和暂存区状态
• git log：查看提交历史
• git stash：临时保存当前修改
• git checkout -- 文件名 或 git restore：撤销工作区改动

git rebase用过吗，说一说?

git merge 保留两边原来的历史，然后新建一个"合并提交"把它们接起来。

你在 feature 分支上执行：

A --- B --- C   main
       \
        D --- E   feature

• main 走到了 C
• feature 从 B 分出去，提交了 D、E

这时候别人又在 main 上提交了两个新提交：

A --- B --- C --- F --- G   main
       \
        D --- E   feature

现在你想把 main 的最新代码整合到 feature，就有两种常见方式：

• merge
• rebase

git merge 的结果

A --- B --- C --- F --- G   main
       \                 \
        D --- E ---------- M   feature

这里的 M 就是一个新的 merge commit。我把 main 和 feature 的改动合并起来了,特点是不该写已有历史,会多出现一个 merge commit,比较安全

git rebase

rebase 的思路是：

不保留你原来分叉的位置，而是把你当前分支的提交"重新接到"目标分支最新提交后面。

A --- B --- C --- F --- G --- D' --- E'   feature
                             
main 仍在 G

会改写提交历史,不会产生 merge commit,冲突可能会在"每个提交重放时"出现

如果D'和E'都修改了和最新版本有冲突,都修改了同一个内容,就会导致合并到D'的时候就停下来,让你修改正确,然后E'的时候也会停下来,让你修改正确

Git pull和git fetch的区别

git fetch 只拉，不合；git pull 既拉又合。

git fetch

• 只会把远程仓库的最新提交拉到本地
• 不会自动合并到你当前分支
• git fetch 执行之后,远程最新代码会被拉下来,比如更新到 origin/main,但你本地 main 不会立刻变化,这时候你可以主动用指令查看修改啥了,自主选择 git merge 还是 git rebase

git pull=git fetch + git merge

• 先拉远程最新代码
• 再自动合并到当前分支

暂存区 工作区 和 远端仓库有什么区别?

工作区是什么?

工作区就是你平时真正编辑代码的地方，也就是项目文件夹。你刚改完，还没 git add，这时候改动只存在于工作区。

暂存区是什么

暂存区 是 Git 里一个"临时收集本次准备提交内容"的地方。就是把工作区里当前这些改动，加入到暂存区。

本地仓库是什么

git commit -m "xxx"后,就是把暂存区里的内容提交到本地仓库。

本地仓库保存的是：

• 提交历史
• commit 记录
• 分支信息

本地仓库 = 你电脑上的 Git 版本库。

远程仓库是什么

远程仓库就是：

• GitHub
• GitLab
• Gitee
• 公司自己的远程仓库

执行git push 才是把本地仓库里的提交推到远程仓库。

2.前端性能优化了解过哪些?

前端的性能优化可以从 3 个方面考虑

• 传输更快
• 体积更小
• 加载更快

2.1 传输更快

• 增加带宽
• CDN 分发
• 浏览器缓存过期配置,比如缓存几小时
• 使用 HTTP2
• 聚合接口

增加带宽

最简单的传输更快就是增加预算,购买带宽

CDN 分发

如果用户离我们网站服务器的距离比较远,比如我们去访问海外网站,就会很慢,使用 CDN分发网络,相当于把静态资源提前放在了你附近的服务器,缺点是:成本较高

更改缓存策略

通过修改缓存策略,来设置浏览器缓存

长期缓存:适合静态资源(图片 字体 打包后的 css,js) 缓存时间:1年或者更长

短期缓存:适合 HTML 页面,动态内容,频繁更新的资源 缓存时间:几分钟到几小时

条件缓存:需要验证但你不经常改变的内容 缓存时间:配合 ETag/Last-Modified

无缓存:适合敏感数据 实时 api
浏览器可以理解有有上限的仓库,虽然你设置了长期缓存,但是如果你很久没有用,浏览器空间不足也会删除

聚合接口

前端访问多次后端接口,可能会产生请求排队和阻塞,导致数据加载耗时过长,可以让后端提供一个聚合接口,一个接口返回某个页面需要的所有数据,或者自己搭个 nodejs 中间层,来做请求聚合

2.2 体积更小

• 图片资源的体积减小
• 网站本身代码的压缩
• Gzip 自动压缩

图片资源的体积减小

将图片压缩,或者将图片格式换成 WEBP 格式,能够减少百分之 20 以上的文件体积

网站本身代码的压缩

用一些构建工具比如 vite webpack 等

Gzip 自动压缩

浏览器告诉服务器,我支持 Gzip 压缩(通过发送请求头),服务器压缩完,通过响应头告诉浏览器这是压缩过的

浏览器收到文件后会自动进行解压

2.3 加载策略

• 延迟加载(懒加载)
• 按需加载
• 分层加载
• 预加载

延迟加载(懒加载)

用户看不到的内容就先不加载,可以通过 img 标签自带的属性 loading="lazy"实现懒加载

按需加载

利用代码分割技术,把原本庞大的代码包拆分成多个小模块,根据用户实际需要的功能来加载对应的代码,比如之前网站的所有 css 文件和 js 文件是在一起的,可以利用分割技术,分割成多个小文件,访问哪个页面时候,加载哪部分的代码

分层加载

核心思想,先快后好,先让用户立即看到内容

1.缩略图,比如项目列表是低清图,点击去是高清图

2.比如先显示一个模糊的浏览,慢慢再显示原图

预加载

在用户访问之前就把资源准备好,让体验更流畅,使用前应对网站进行分析,预加载太少效果不明显,预加载太多又会产生浏览浪费

2.4 网站性能分析工具

浏览器开发者工具中的 LightHouse