本文目录一览：
- 1、git 文件太大时怎样处理
- 2、Git不小心commit了很大的文件怎么办？
- 3、git 超过100M文件的解决方法
- 4、git 大文件管理操作方法
- 5、提交git,文件大于100M 限制的解决措施
- 6、Git LFS使用--Netlify Large Media
git 文件太大时怎样处理
你可以把那段需要做成表情的视频先截取出来，存为一般的视频就好，再去下载一个叫“格式工厂”的软件，转格式，转格式的时候可以设置图片大小。把大到小设置小一点就行了。谢谢采纳！
Git不小心commit了很大的文件怎么办？
1 git add . 2 git commit -m 3 git pull 4 git push
拉闸，不小心commit了超过10M的文件,拉闸。 出现了一个错误。
这时候不小心将一个很大的文件添加到库中，即使删除，记录中还是保存了这个文件。以后不管是拷贝，还是push/pull都比较麻烦，尤其是在做CI时的耗时很痛苦。
1、若知道你的大文件是什么类型的，比如.gz或者.jar等，可以删除匹配xxx的所有文件：比如我很明显就提示我是xxx.jar 太大了。 因为我打了整个项目的jar包,接近100MB肯定大
2、若不知道，想查看下目前git库中有哪些大文件，可以用底层命令verify-pack识别出大对象：
3、释放空间
4、把修改强制推送到远端
搞定
git 超过100M文件的解决方法
对于部分非二进制的文件这样的可以解决单个文件过大的问题
设置上限为 500M
如果方法一不行，git push依旧说文件过大，
删除已经提交但是还没有push成功的文件，修改文件大小后重新提交
简单操作，3条命令就可以了
git 大文件管理操作方法
Lets take a look at the workflow when you need to check large files into your Git repository with Git LFS. For example, if you want to upload a very large file and check it into your Git repository:-.git文件夹过大
Once a certain file extension is marked for tracking as a LFS object you can use Git as usual without having to redo the command to track a file with the same extension:-.git文件夹过大
Make sure that .gitattributes is tracked by Git. Otherwise Git LFS will not be working properly for people cloning the project:-.git文件夹过大
Cloning the repository works the same as before. Git automatically detects the LFS-tracked files and clones them via HTTP. If you performed the git clone command with a SSH URL, you have to enter your GitLab credentials for HTTP authentication.-.git文件夹过大
If you already cloned the repository and you want to get the latest LFS object that are on the remote repository, eg. for a branch from origin:-.git文件夹过大
当本地仓库积攒了比较多版本的LFS导致体积较大的时候，可以通过以下命令进行清理：
git lfs prune
私有lfs仓库设置 .lfsconfig 配置文件，需要一并提交到 Git，否则Clone的时候不会去配置的地址上找
git config -f .lfsconfig lfs.url
cat .lfsconfig
[lfs]
url =
提交git,文件大于100M 限制的解决措施
**上面提到Git Large File Storage( ).直接访问有 github 开源的 LFS 大文件上传方法就可以解决;
具体方式下面贴出来,也给自己备注下
备注:如果执行生面方式有失败的情况,可能是之前有提交过,清除下提交缓存
然后从新正常git提交操作
Git LFS使用--Netlify Large Media
Git LFS一直都想尝试，但，GitHub上
1G的存储，1G的带宽是，这量实在是。。。在2月26日，Netlify宣布了流量限制100G，也宣布新的功能，图像转换功能为流量限制做铺垫，以及这个转换功能所附带的大文件存储。一半伤心一半心动。虽然转换功能也有限制，2500次每月（同一次相同转换会缓存，只消耗1次次数），所以对于大部分中小型网站来说都够用了，当然100G的带宽，也是一样。-.git文件夹过大
作为转换功能基础的文件存储，则没提及，可能无限制吧。所以是时候升级啦。
原因涉及到Git的底层原理，很多介绍上只说了会使存储库变的很大，所以要用LFS，但事实上二进制文件就是很大的，用了LFS，最后还不是得下一堆二进制文件。根本原因不是这个，而是Git的底层文件系统。Git的所有文件都存放在 .git\objects 中，而修改是保存一个新的文件，而目录中以hash值引用，旧文件是不会被删除的，删除也是一样。所以整个 .git 文件夹会变得特别膨大。-.git文件夹过大
Git LFS能将二进制存储在别处，在Git中存储的只是标记文件，占用空间十分小。所以，当文件被删除后，空间占用也就少了，不会想原先那样，只增不减。
这里使用Netlify Large Media做存储库。
注意：在初次安装Large Media插件时，可能需要关掉命令终端，重新启动来加载脚本
这是另一大激动人心的功能，能帮我们自动转换图片大小。可以省下我们很多事。或者说我们可以不再准备多套分辨率了，想调用api一样获得
不过在hexo中比较难处理。目前我也只能通过 过滤器 ，把 img 中带 width 、 height 转化为netlify的图像转换api，那样就能得到适合大小的图片，加快页面载入
