0


git远程仓库限额的解决方法——大文件瘦身

Git作为世界上最优秀的分布式版本控制工具,也是优秀的文件管理工具,它赋予了项目成员对项目进行远程协同开发能力,因此受到越来越多的行业从业人员的喜爱。很多优秀的项目管理平台,比如国内的Gitee,国外的Github,也都是以Git为核心操作。但是有些用户,尤其是游戏行业以及媒体行业人员可能会遇到一个问题,那就是随着提交的文件越来越多,项目越来越大,Git的响应速度越来越慢,更烦人的是,在提交到远程仓库的最后一刻,系统可能会提示用户此次提交被拒绝,原因是提交的文件太大,触发平台额度限制(无论是哪个平台),相信很多人在这一刻是崩溃的。

那么该如何避免这种崩溃事件的发生呢?

下面就介绍今天的主角Git LFS(Git Large File Storage),即Git大文件存储技术。

在Git仓库中,对于非文本文件,如各种多媒体文件,软件制品文件,二进制文件等等,这些文件往往体积比较大,使用Git直接管理会导致仓库的体积迅速膨胀,进而导致Git的许多操作变慢,同时也影响仓库上传到远程端。

Git LFS相当于Git的一种插件式增强工具,简单讲,它是在Git仓库使用这些文件的

指针

代替

实际文件

,而把实际文件存储在远程端LFS服务器,同时在本地仓库中实时追踪这些文件的变动。

原理

根据

Git LFS

官方帮助文档描述:

Git LFS是基于Git的 .gitattributs 配置文件的特性,用

smudge

过滤器基于

指针文件

寻找大文件内容, 用

clean

过滤器在对大文件改动时,创建指针文件的新版本。同时还用

pre-push

钩子将大文件上传到Git LFS服务器, 即在

git-push

时, 如果提交中包含被LFS跟踪的大文件,

pre-push

钩子会检测到,并执行上传Git LFS服务器的动作。

因此,如果一个仓库中包含LFS内容,但是在推送时不想推送这类文件,只要加上

--no-verify

选项就行,即:

$ git push --no-verify
--no-verify

选项告诉

git push

完全跳过

pre-push

钩子。

前面提到被LFS管理的文件,本地仓库中保存的内容实际上是指针文件,其格式类似于下面这样:

$ git show HEAD:2.svg

version https://git-lfs.github.com/spec/v1
oid sha256:158213f90f8b27012034c6f58db63e1861b12aa122d98910de311bf1cb1e50a0
size 14651
(END)
version

表示LFS的版本

oid

表示文件对象的唯一hash值

size

表示文件的大小

使用场景

场景一:

有一天你在Gitee上寻找感兴趣的项目,很快你就找到一个有价值的游戏项目,并且决定马上fork并clone下来:

$ git clone [email protected]:hightest/lfs-demo.git my-project
Cloning into 'lfs-copy'...
Enter passphrase for key '/home/git/.ssh/id_ed25519':
remote: Enumerating objects: 24, done.
remote: Counting objects: 100% (24/24), done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 24 (delta 7), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (24/24), done.
Resolving deltas: 100% (7/7), done.
Enter passphrase for key '/home/git/.ssh/id_ed25519':
Updating files: 100% (9/9), done.
Enter passphrase for key '/home/git/.ssh/id_ed25519':
Filtering content: 100% (5/5), 1.51 MiB | 257.00 KiB/s, done.

你只是稍微修改了一个示例文件example.lfs,然后顺便git diff一下,看下修改变化:

$cd my-project
# edit example.lfs
$ git diff
diff --git a/example.lfs b/example.lfs
index 9550b5b..8bfca2b 100644
--- a/example.lfs
+++ b/example.lfs
@@ -1,3 +1,3 @@
version https://git-lfs.github.com/spec/v1
-oid sha256:fa3b58d0150ccbaed40ab94fd5574ae8225e83117c076b586ef08ff38be8d923
-size 69
+oid sha256:d8f84506d6b9e804852c3b15b921893606b4c2cbe388d1cc118bd42101eed2a8
+size 63
(END)
git diff

显示的修改变动不是你期望的,为啥会出现这个差异呢?

如果你看过前面的原理部分,那你马上就能看明白,这是LFS指针文件的差异,这说明你下载的这个仓库是用了LFS来管理了文件。

此时仓库的实际存储的文件大小只有132 Bytes, 而它的实际大小是9.18 MiB, 大小相差几个数量级。

这样做的好处非常明显,对于很大的文件,可以只用很小的空间来管理它。

image.png


场景二:

作为一名游戏开发人员,你一直想设计开发一款好玩的游戏,场景一中使用的项目给了你灵感,你决定在这个基础上进行深度开发,你在这个仓库里面加入了很多图片文件,音效文件等游戏资源文件,开始每次git add/commit/push都很顺利,但有一次你把这些文件打包成

biger.zip

,想一次推送到远程仓库,结果最后推送失败,系统提示如下:

$ git push origin master

Enter passphrase for key '/home/git/.ssh/id_ed25519':
Locking support detected on remote "origin". Consider enabling it with:
  $ git config lfs.https://gitee.com/hightest/lfs-demo.git/info/lfs.locksverify true
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 6 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 388.92 MiB | 928.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [GNK-6.1]
remote: error: File: bcd245bbd11e6b1d71b5d3073f57007c4c002c4a 388.97 MB, exceeds 300.00 MB.
remote: Use command below to see the filename:
remote: git rev-list --objects --all | grep bcd245bbd11e6b1d71b5d3073f57007c4c002c4a
remote: Please remove the file from history and try again. (https://gitee.com/help/articles/4232)
To gitee.com:hightest/lfs-demo.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'gitee.com:hightest/lfs-demo.git'

很明显,由于推送的单个文件太大,超过配额300 MB,所以推送被拒绝。

同时,也能明显感觉得到,Git的各种基本操作变得卡顿、延迟。

这个时候,根据场景一的启发,你想到可以使用Gtiee的LFS服务,将大文件使用LFS管理,而仓库只保存它的指针信息,就能避免此问题。

  • 使用LFS管理历史大文件:

如果一个仓库中原来已经提交了一些大文件,此时即使运行

git lfs track

也不会有效的。

为了将仓库中现存的大文件应用到LFS,需要用

git lfs migrate

导入到LFS中:

$ git lfs migrate import --include-ref=master --include="biger.zip"
migrate: override changes in your working copy?  All uncommitted changes will be lost! [y/N] y
migrate: changes in your working copy will be overridden ...
migrate: Sorting commits: ..., done.
migrate: Rewriting commits: 100% (11/11), done.
  master        f9be3c554e9010ea5e0e23a6a0c6e53dca6c23b0 -> 53d5e655fe7cfd985f75384b92ac5414ad2ff394
migrate: Updating refs: ..., done.
migrate: checkout: ..., done.

–include-ref 选项指定导入的分支

如果向应用到所有分支,则使用–everything选项

–include 选项指定要导入的文件。可以使用通配符,批量导入。

上述操作会改写提交历史,如果不想改写历史,则使用

--no-rewrite

选项,并提供新的commit信息:

$ git lfs migrate import --no-rewrite -m "lfs import"

将本地历史提交中的文件纳入到LFS管理后,如果重改了历史,再次推送代码时,需要使用强制推送。

这里选择改变提交历史,所以还需要使用

--force

强制推送:

$ git push origin master --force

Enter passphrase for key '/home/git/.ssh/id_ed25519':
Locking support detected on remote "origin". Consider enabling it with:
  $ git config lfs.https://gitee.com/hightest/lfs-demo.git/info/lfs.locksverify true
Uploading LFS objects: 100% (8/8), 419 MB | 0 B/s, done.
Enumerating objects: 38, done.
Counting objects: 100% (38/38), done.
Delta compression using up to 6 threads
Compressing objects: 100% (37/37), done.
Writing objects: 100% (38/38), 136.26 MiB | 943.00 KiB/s, done.
Total 38 (delta 12), reused 10 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [GNK-6.1]
To gitee.com:hightest/lfs-demo.git
 + cefd169...53d5e65 master -> master (forced update)

至此,已经将历史提交中的大文件迁移到远程LFS服务器,本地Git仓库,只保留这个大文件的指针文件,所以推送也不会再触发额度限制。推送成功之后,远程仓库就与本地保存一致,如场景一中的图示,它只管理这个大文件的指针文件。

推送成功后在仓库管理页面可以看到:

image.png

这里显示的是LFS Server实际管理的文件的大小,而Git仓库管理的大小则为134 Bytes!

image.png


场景三:

作为Git重度使用者的你,日常工作中必须使用Git管理你的文件,但是经历过上面对历史提交重写,并上传LFS服务器的你,学会了一开始在仓库中配置LFS功能,保证每一次提交、推送都保持完美。

在一个新的项目中,在初始阶段,你已经配置好了LFS。此时有更大一个文件

biggerthanbigger.zip

,大小是778M,远远超过单个文件大小限制。

  • 使用LFS管理新增大文件
$ cd new-project
$ git add biggerthanbigger.zip
$ git commit -m "add bigger than bigger zip file"

然后提交到远程仓库, 因为使用了LFS服务,如果不出意外,这次不会被拒绝。

$ git push origin master
Enter passphrase for key '/home/git/.ssh/id_ed25519':
Locking support detected on remote "origin". Consider enabling it with:
  $ git config lfs.https://gitee.com/hightest/new-project.git/info/lfs.locksverify true
Uploading LFS objects: 100% (3/3), 1.2 MB | 0 B/s, done.
Enumerating objects: 11, done.
Counting objects: 100% (11/11), done.
Delta compression using up to 6 threads
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 1.56 KiB | 1.56 MiB/s, done.
Total 10 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [GNK-6.1]
To gitee.com:hightest/new-project.git
   dfe8b09..5f03bab  master -> master

但实际上,意外是很可能发生的!

因为推送的文件过于大,很有可能因为超过LFS的配额而推送失败,虽然LFS是专门用来管理大文件的,但是也不能无限制存放大文件,毕竟这不是网盘。


本文转载自: https://blog.csdn.net/2301_77186032/article/details/139234706
版权归原作者 冰落的泪 所有, 如有侵权,请联系我们删除。

“git远程仓库限额的解决方法——大文件瘦身”的评论:

还没有评论