本章主要测试讲解

• git lfs 少量基本命令使用；
• 使用 Git/Git LFS 搭配 gitlab 管控大文件之测试。

测试过程内容较多，每个步骤都逐一截图以便真实说明，也有列示用法。若不感兴趣，可直接查看总结部分。

测试过程

前置说明

• 1、Git 本身作为代码管控软件，是以代码为主，没有直接管控到比较大的文件。
• 2、目前比较流行的 git 管理大文件的方式是使用 git-lfs。
• 3、git-lfs 是 git 的一个插件，官网说明如下：

1.png

• 4、使用比较简单，简单两三步就可完成大文件的提交。
• 5、gitlab 新版本默认已经支持 lfs，在配置文件 gitlab.rb 中可见：

2.png

预期中可能出现的问题

• 1、由于是管理到大文件，所以在 push 到远程服务器或者者从远程服务器 pull 可能会由于网络带宽、文件大小、同时操作人员过多等因素导致操作耗时较长。
• 2、git 记录每次 add、commit 等操作，又以大文件为主，本地的.git 文件夹可能会极速增大。
• 3、gitlab 服务器若是还增加定期备份，由于文件管理可能导致 gitlab server 需要较大的硬盘存储数据。

大概流程

• 1 安装 git lfs 插件
• 2 准备两份大文件，两份 txt，分别作为文件管理和代码管理。
• 3 在 gitlab server 新建仓库，作为文件管理远程仓库。
• 4 使用 git lfs 将文件上传到 gitlab server 远程仓库。
• 5 克隆远程仓库到本地，查看文件能否完整。

测试步骤

下载安装插件

在git lfs 官网下载插件并安装。

本地项目准备

本地新建文件夹 gitLfsTest，并准备两个较大压缩包文件作文件管理对象。同时新建两份 test3.txt，test4.txt 作为代码管理对象。

如下图：

3.png

创立远程仓库

在 gitlab server 创立一个仓库，作为远程仓库

4.png

初始化文件夹为本地 git 仓库，初始化 git lfs。

执行命令：

git initgit lfs install

如下图：

5.png

使用 git lfs 追踪大文件

使用 git lfs 追踪（track）大文件（*指代所有），执行之后，在文件根目录会出现.gitattributes 文件，内容即为追踪的大文件类型。
执行命令：

git lfs track "*.zip"

如下图

6.png

确保.gitattributes 文件会被增加到追踪（tracked）

执行命令：

git add .gitattributes

一般来说假如都是执行的git add .，那就没有必要再这样作

如下图：

7.png

到这里，git lfs 追踪管理大文件就基本完成了，后续就像是管理一般代码一样，进行 add，commit，push 等操作。

将 gitLfsTest 专案 push 到远程仓库。

当然，要记得先 add，commit。
注意：初次 add 时，我使用的是add .，会增加 2 个 zip 文件合计 2.26G 左右，2 个 txt 文件，总共 4 个文件，使用 time 指令记录耗时：

time git add .

如下图：

8.png

再 commit：

time git commit -m '首次提交两个大文件'

如下图：

9.png

后续常规，增加远程仓库地址，推送到远程仓库：

git remote add origin http://192.168.28.83/david/gitlfstest.gittime git push -u origin master

如下图：

10.png

远程仓库内容如下：

11.png

可见两个 zip 包后面有 LFS 标识。

修改本地的 zip 包，再上传到远程仓库。

修改文件前，留意下.git 文件的大小,如下图：

12.png

修改 test2.zip 文件大小
修改前如下图：

13.png

修改后如下图：

14.png

同样的，add，commit，push：

time git add .time git commit -m '修改test2.zip文件大小'time git push -u origin master

如下图：

15.png

远程也是一样有新的 commit 信息

如下图：

16.png

此时，再关注下.git 文件夹的大小

如下图：

17.png

由 2.26G 上升到了 2.99G。
所以，看起来随着修改的次数变多，.git 文件会无休止的增大下去。
不过 git lfs 有相关指令避免它：

git lfs prune

它会删除本地旧的 fls 文件。

如下图：

18.png

从远程仓库 clone 一份 gitLfsTest 项目，查看文件内容。

此时的项目应该是这样的：如下图：

19.png

我们从远程克隆一份下来：

查看内容，注意.git 的大小。如下图：

20.png

可见项目内容是完整的，test1.zip 和 test2.zip 都完整存在。至此使用 git 搭配插件 git lfs 管理大文件的测试就完成。

如下图：

21.png

总结

1. git 配合 git lfs 和 gitlab server 管控大文件操作还算简单方便，在系统安装完插件之后，在 git 管理的项目内：

    # 增加对大文件的追踪(.zip后缀)    git lfs install    git lfs track "*.zip"    git add .gitattributes    # 常规的增加、提交、推送    git add .    git commit -m '{message}'    git remote add origin {origin-url}    git push -u origin master    # 删除本地旧的fls文件    git lfs prune

2. 即使是针对大文件，add，commit 等在本机的 git 指令仍旧不算耗时；
3. 在将项目需要放到远程 server 管理时，主要的耗时，来源于 push 和 clone 等跨主机操作，因而可以考虑到主要耗时取决网络。
4. .git 中确实会保留 fls 文件操作历史，导致 size 变得很大，不过可以使用
   git lfs prune尽量减少大小。
5. 更多git lfs指令，可參看official man pages.,或者者直接終端輸入：

    git lfs help <command>    # 或者    git lfs <command> -h