git lfs是专门用来解决大文件上传的工具,它的实现原理:
将需要添加到LFS的文件额外添加到LFS专属仓库中,仓库只保留这些大文件的文本链接,当从远程仓库拉取文件时,LFS的钩子将自动将这些文本链接恢复为LFS的实际内容,如图所示:
使用LFS管理仓库,用户在clone的时候可以更快,并且也不能察觉出用了lfs
几点疑惑:
1.LFS支持多大的文件存储?
github目前支持1G,bitbucket和gitlab暂时不知道
2.1G的存储空间不大,那么应该也存不到多少东西吧?
凡是上传到LFS的文件都会进行压缩,网上有人上传1G大小的文件,经过LFS压缩只有几m
3.既然压缩了大小,那么本地的文件是不是也压缩?上传速度会加快吗?
不会,和普通push一样
首先下载LFS的安装包,点击安装后,执行
git lfs install
该步骤执行一次就够了,此后上传文件和普通的操作类似,只是多了lfs
命令
LFS还会创建post-checkout
、post-commit
、post-merge
、pre-push
几个全局钩子。当我们在一个使用 LFS 的仓库执行类似checkout
、commit
、merge
、push
的 Git 操作
我们需要另外对大文件进行分类管理,将其传到LFS仓库
git lfs track "*.pdf"
#将路径下的所有pdf传送到LFS
执行完上述命令后会在仓库中创建一个.gitattribute
文件,里面记录的内容就是track
的信息
git的钩子就是通过该文件确定当前仓库是否通过LFS管理,所以不要忘了将它添加
git add .gitattribute
然后就可以像正常操作那样提交了
git add *.pdf
git commit -m "add pdf"
git push origin master
这个改造过程只会把当前这次 commit 的指定类型文件改成用 LFS 才存储,而不会影响所有历史记录。对于我们的 SDK 仓库,仓库本身已经非常庞大,直接这么改造是没有任何瘦身效果的。所以最好的做法就是重新创建一个仓库,把各个分支最新的快照同步过来。
很多时候是因为buffer不够大造成的
出现下面类似问题:
Delta compression using up to 4 threads.
Compressing objects: 100% (8210/8210), done.
Writing objects: 100% (11506/11506), 21.75 MiB | 0 bytes/s, done.
Total 11506 (delta 2213), reused 11504 (delta 2211)
efrror: RPC failed; result=56, HTTP code = 200
atal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
Everything up-to-date
解决:
git config http.postBuffer 524288000
#这里将buffer设置为500M,可以自定义