网络请求优化

网络请求优化可以从以下几个纬度进行思考

1. 减少网络请求耗时
2. 提高资源请求效率
3. 减轻服务端压力

CDN

使用 CDN 可以有效提升请求效率，减轻源服务器压力，但是要注意只有静态资源才适合使用 CDN，比如图片、HTML 文件、模版等不经常改变的数据。

原理

CDN 的原理就是在各个位置部署 CDN 服务器，用户在发起请求时，直接请求距离最近的 CDN 服务器，可以避免因为地理位置太远导致的耗时高。用户请求 CDN 服务器时，CDN 服务器会优先去缓存中寻找目标数据。

如果有则命中缓存，直接返回。命中缓存可以有效提升访问速度。

如果没有命中缓存或者缓存已经过期，CDN 服务器会去源服务器请求数据并返回给客户端，同时将数据缓存。

预热

预热就是提前让 CDN 去源服务器请求数据并缓存，保证用户在首次访问到 CDN 服务器时能够直接命中缓存，而不需要请求源服务器。
比如在上线新活动之前，可以提前预热 CDN，不仅能加快首批用户的请求时间，还可以减轻源服务器的压力

刷新

刷新分为 URL 刷新和目录刷新

• URL 刷新是直接将 CDN 节点上的缓存文件直接删除。重新请求最新的资源

• 目录刷新是将 CDN 节点上的文件标记为过期，但是会和源站对比过期时间，只有真正过期的数据才会重新请求。

本地 DNS 映射

网络请求的第一步基本都是 DNS 解析，而 DNS 解析的耗时跟当时所处的网络环境有很大关系，虽然 DNS 解析是有 cache 的，但是因为 cache 有过期时间，所以不能保证每次请求都能命中 cache。如果可以节省掉这部分时间对网络性能是有一定提升的。

DNS 解析说简单点无非就是输入域名，输出 IP 地址，那么 DNS 映射就是模拟了这一个行为，在客户端本地维护一个映射表，避免发起 DNS 解析。

但是简单的映射不能 cover 住所有场景，还需要以下能力进行兜底

1. 映射表需要有版本概念，定期从服务器更新最新版本的映射表
2. 可以强制推送新的映射表给客户端，避免本地长时间使用错误的映射表
3. 映射的 IP 无法使用时可以回滚使用默认的 DNS 解析服务

链接复用

HTTP 请求支持复用，在 header 里设置 Keep-Alive 参数，用于告知服务器保存这个链接，后面还会继续使用。

一次请求的过程大概可以分为 DNS 解析 -> TCP -> SSL 三个步骤，如果多个请求的域名是相同的，可以复用同一个链接，节省频繁建立链接带来的开销。

预链接

预链接是在链接复用的基础上的优化，在 APP 启动后，提前为后续重要的请求建立好 HTTP 链接，等真正发起请求时就可以复用这个链接，减少请求耗时。

简介

LFS 全称 Large File Storage，顾名思义是用来存储大文件的。在 Git 中，每次提交都会将改动转为二进制文件保存起来，但是对于图片、视频、音频等本来就是二进制的文件，Git 无法识别出差异，所以每次提交都会生成一个新的拷贝。也就是说，一个 100M 的图片，哪怕只改了一点点，提交新版本后它都会在仓库里占用 200M 的空间。

为了解决这个问题，GitHub 提出了 LFS，将图片、视频、音频等大文件存储到主仓库外的一个仓库里。

原理

LFS 的原理是将大型二进制文件存储到主仓库外的另外一个仓库里，本地仓库并不会存储这些大文件，仅仅是保留一个指向大文件的指针，当用户切换到某一分支时，LFS 会根据当前分支的情况下载对应的大文件。

使用

下载 LFS

可以官网下载安装。

Mac 用户可以通过 homebrew 安装 brew install git-lfs。

安装 LFS

进入目标仓库目录，然后运行 git lfs install 安装 LFS。

使用 LFS

通过下面命令选择你希望 LFS 管理的文件类型或者目录。

git lfs track "*.psd"

选择好后别忘了添加 .gitattributes。

git add .gitattributes

一切就绪，后面当我们提交的文件中包含 .psd 类型的文件时，Git 会自动使用 LFS 对其进行管理。

1
2
3

git add file.psd
git commit -m "Add design file"
git push origin master

结论

建议二进制文件都使用 LFS 进行管理，避免频繁的改动使仓库越来越大，如果当前 Git 仓库已经提交了很多大文件变得很大，还有个后悔药可以吃。

变基本名 rebase ，也不知道是谁给它起了这么拗口的名字。

上一篇文章我们学习了 merge 操作，知道了两个分支之间同步代码可以使用git merge命令，但是 merge 命令有一个小缺点让一部分完美主义者无法接受，那就是每次 merge 完成之后，都会生成一个新的 commit。

假如频繁的从 master 分支同步代码到 develop 分支，那 develop 分支上会多出来很多 merge 节点，这些节点有些人觉得很多余，污染了提交历史，让它阅读起来很困难。也有一部分人觉得应该保留开发过程中的每一个操作，方便追踪问题，所以不应该去掉这些节点。两种想法没有对错，仅看个人习惯，如果想同步代码后不产生新的节点，那可以使用一个新的命令git rebase。

流程

base 基本点，在 Git 中指分支开始分叉的那个节点。

re 重新设置。

rebase 可以理解为重新设置基本点，也就是修改分支分叉的位置。

1. 切换到目标分支

使用git checkout develop命令，切换到 develop 分支，develop 可以替换为任何目标分支。

2. 变基

使用git rebase master命令，将 master 代码 rebase 到 master，如果没有冲突则 rebase 完成。

3. 解决冲突

如果产生了冲突，则需要先解决冲突，冲突解决完毕后，使用git rebase --continue命令继续执行 rebase 操作。如果想终止此次 rebase 可以使用git rebase --abort命令。

原理

下图展示的是将 master 分支代码 rebase 到 develop 分支的过程：

从图中我们可以发现，在执行 rebase 之前，develop 分支是基于 C2 节点的，执行 rebase 操作后，develop 分支的基点移动到了 C4，而 develop 分支的 C5 和 C6 节点会重新在 C4 之后再重放一遍。

C5 和 C6 节点看起来是从 C2 节点后移动到了 C4 节点后，但实际上 Git 并没有移动 C5 和 C6 节点，而是在 C4 节点后，又提交了两个跟 C5 和 C6 相同的节点 C5’ 和 C6’，C5 和 C5’ 除了 commit id 不同，其余完全一样。

rebase 黄金法则

永远不要对一个公共分支执行 rebase 操作。

在执行 rebase 操作前，请默念此法则三遍。一旦对公共分支执行了 rebase 操作，那整个分支将会变得不可维护。

在 develop 分支开发完成后，需要将 develop 分支的代码同步到 master，这时 merge（合并）就派上了用场。

merge 是 Git 中非常常用的一个命令，并行开发中各个分支代码的同步基本都要使用 merge。

流程

1. 切换到目标分支

使用git checkout master命令，切换到 master 分支，master 可以替换为任何目标分支。

2. 合并

使用git merge develop命令，将 develop 代码合并到 master，如果没有冲突则合并完成，同时会生成一个新的 commit 提交，commit 的内容就是 merge 的内容。

3. 解决冲突

如果产生了冲突，则需要先解决冲突，冲突解决完毕后，使用git add命令跟踪解决完的改动，同时也会去掉该文件的冲突标记，最后使用git commit命令提交这次 merge。

结语

合并完成后，临时分支就可以删除了。

比如，开发者在 develop 分支完成开发，并将 develop 分支的代码合并回 master 分支，合并完成后，develop 分支就完成了它的使命，可以删除。

还有一种情况是开发过程中同步主线代码到开发分支，也是使用 merge 命令进行操作，不同的是这次可不要把 master 分支删掉哦。

下图展示的是将 master 分支代码同步到 develop 分支的过程：

简介

每次提交新版本，Git 都会把新版本连接到上一个版本的后面，串成一条时间线，这个时间线就是分支。

分支管理是 Git 的强项，有别于 SVN 的分支是整个项目的一个拷贝，Git 的分支仅仅是一个指向某次提交的指针。所以 Git 创建、删除分支有天然的优势，仅仅创建、删除一个指针即可，成本极低。

背景

随着项目的不断开发，仓库自然而然会变得越来越大，如果项目中只是纯文本文件，那仓库的大小增加的会非常缓慢。但是如果仓库中存放了视频、图片、音频等比较大的二进制文件，那这个仓库估计经历几次提交就爆炸了。尤其 clone 仓库时，如果你面对几十个 G 的仓库，估计还没开发心态就崩了。

远端

根据 Git 的特点，每个人本地都是一个完整的版本库，没有服务器其实也是可以工作，只要两台电脑能够互相连接上，就可以进行数据的交换。但是在实际使用时，没人会通过这种方式互相推送修改，因为两台电脑很有可能不在一个局域网下。所以 Git 一般也会有一个中央服务器，他的存在就是为了方便大家进行数据的交换。

远端指的就是这台中央服务器上的版本库。

git commit 会将暂存区的所有文件拿出来，生成一个新的版本。那么在背后 git commit 都做了哪些操作呢，下面详细介绍下。

前文有了解到，git add fileName 命令会将指定文件加入到暂存区，那么 git add 背后都做了哪些操作，下面详细介绍下。

版本库

在前面的文章 《Git-创建新仓库》中我们了解到，每个仓库下面都有一个名为 .git 的隐藏文件夹，这个文件夹其实就是版本库，这里面就藏了 Git 版本管理的秘密。