辽宁建设厅的证到底在哪个网站查,如何诚信网站平台建设,青岛app软件开发公司,广告设计是干什么的Git作为世界上最优秀的分布式版本控制工具#xff0c;也是优秀的文件管理工具#xff0c;它赋予了项目成员对项目进行远程协同开发能力#xff0c;因此受到越来越多的行业从业人员的喜爱。很多优秀的项目管理平台#xff0c;比如国内的Gitee#xff0c;国外的Github#…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.svgversion https://git-lfs.github.com/spec/v1
oid sha256:158213f90f8b27012034c6f58db63e1861b12aa122d98910de311bf1cb1e50a0
size 14651
(END)version表示LFS的版本
oid表示文件对象的唯一hash值
size表示文件的大小
使用场景
场景一
有一天你在Gitee上寻找感兴趣的项目很快你就找到一个有价值的游戏项目并且决定马上fork并clone下来
$ git clone gitgitee.com: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.lfsb/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, 大小相差几个数量级。
这样做的好处非常明显对于很大的文件可以只用很小的空间来管理它。 场景二
作为一名游戏开发人员你一直想设计开发一款好玩的游戏场景一中使用的项目给了你灵感你决定在这个基础上进行深度开发你在这个仓库里面加入了很多图片文件音效文件等游戏资源文件开始每次git add/commit/push都很顺利但有一次你把这些文件打包成 biger.zip想一次推送到远程仓库结果最后推送失败系统提示如下
$ git push origin masterEnter 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-refmaster --includebiger.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 --forceEnter 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仓库只保留这个大文件的指针文件所以推送也不会再触发额度限制。推送成功之后远程仓库就与本地保存一致如场景一中的图示它只管理这个大文件的指针文件。
推送成功后在仓库管理页面可以看到: 这里显示的是LFS Server实际管理的文件的大小而Git仓库管理的大小则为134 Bytes! 场景三
作为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.gitdfe8b09..5f03bab master - master但实际上意外是很可能发生的
因为推送的文件过于大很有可能因为超过LFS的配额而推送失败虽然LFS是专门用来管理大文件的但是也不能无限制存放大文件毕竟这不是网盘。
