本篇文章给大家带来了关于GIT仓库瘦身及GIT LFS迁移说明的相关知识，希望对大家有帮助。
之前一些git项目上 CI/CD，发现jenkins git clone失败，设置depth及clone时间之类的无果。只能考虑仓库瘦身之类的策略。发现仓库有不少的二进制文件，且这些二进制文件变更还挺频繁，这种操作会导致git仓库成倍增长极速膨胀，git本身只适合管理文本文件。
另外说一则有趣的往事，之前有个同事是图形编程，这个语言源码是图片形式的，而且一个文件又特别大，上git管理，小公司项目变更又频繁，导致没多久公司内部搭的git服务器硬盘居然就给他的几个git仓库给占满了。
虽然git一直不适合管理二进制文件，不过现在 git 也好像默认提供了git lfs 这个专门用来管理大文件的插件。
基本原理简单来说就是使用类似一个文件指针（文本）代替实际的文件存储，git只存储文件指针的变更历史而不是整个二进制文件，并且在使用的时候，自动提供hook，方便在如clone、pull、reset等操作会自动去获取这些文件指针的源二进制文件，同样更新二进制文件commit的时候，git 会自动将源文件转成文件指针进git log，同时源文件上传lfs。所以在用户层面，GIT LFS的使用其实是无感的。
上面简单介绍了一下GIT LFS，接下来直接将如何迁移，至于为什么直接讲迁移而不是从0开始如何使用LFS。
是因为往往是git仓库用着用着发现，仓库好大、clone好慢，然后才是想着用LFS。
迁移需要我们有仓库的管理员权限，并且将保护分支之类取消保护；
具体LFS迁移主要分为以下几步。
迁移前最好做好备份，并且和团队同事沟通好，毕竟操作涉及-f高危操作，容易背锅。
部分自建git 服务的话，可能需要服务端配置开启LFS，比如gitlab。
windows 的git安装包自带了该插件，不需要另外安装，其他平台可自行安装，链接。
在命令行尝试以下命令。
git lfs
如果有类似help文档信息输出，就是已经有git lfs客户端了。
git-lfs/2.11.0 (GitHub; windows amd64; go 1.14.2; git 48b28d97)git lfs <command> [<args>]Git LFS is a system for managing and versioning large files in association with a Git repository. Instead of storing the large files within the Git repository as blobs, Git LFS stores special "pointer files" in the repository, while storing the actual file contents on a Git LFS server. The contents of the large file are downloaded automatically when needed, for example when a Git branch containing the large file is checked out.Git LFS works by using a "smudge" filter to look up the large file contents based on the pointer file, and a "clean" filter to create a new version of the pointer file when the large file's contents change.It also uses a pre-push hook to upload the large file contents to the Git LFS server whenever a commit containing a new large file version is about to be pushed to the corresponding Git server.
而后需要执行以下命令配置LFS全局环境，只需要配置一次，同时也会去更新当前仓库的hooks
git lfs install
lfs迁移基本思想：lfs重写本地历史—>force push覆写远端，达到迁移的效果。
所以我们最好将本地仓库与远端同步，并且将所有的远端分支都创建本地分支；
而后cd到自己本地仓库，执行以下下命令，–include里面是glob表达式，自行添加想LFS管理的文件名，–everything代表所有本地分支
git lfs migrate import --include="*.bin,*.lib,*.so,*.dll,*.a,*.param,*.zip,*.gz" --everything
migrate: Sorting commits: ..., done. migrate: Rewriting commits: 100% (193/193), done. develop bacb490a80ea46d73bd3866c2e7cf7ad199ce5eb -> 72884bcb4629417bad73ea3d485d08a0708909cd feature/npu-platform a3645632756becc527c7f4d58514b3c479f824d3 -> e227900a3903b3a6955e4dffee48daeceac6cdff master 1ccdecdcb4b5d6224a6e24c6f87793bfcc15ee4c -> 1d9fc2139600ef3d92a20d65bb5db89021b8c488 0.1.0 07c6b2aa732506f1cc88cedb551f37f376b6efa6 -> 8e55193221dfca9f6bb28ccd9cca85af9c5958c9 1.0.0 0f694efcd7aa9df641836e1ea6eebbb730b940b5 -> 3f9e77575120b6e56b34790c998a362116da75f5 migrate: Updating refs: ..., done.
重写完本地分支、tag之类的，
我们在这里可以先执行 git lfs ls-files查看有哪些文件被转成了lfs管理，检查是否有遗漏
这个时候无论在哪个分支，都会出现 .gitattributes 文件，且都会被添加上类似以下内容。
*.bin filter=lfs diff=lfs merge=lfs -text *.lib filter=lfs diff=lfs merge=lfs -text *.so filter=lfs diff=lfs merge=lfs -text *.dll filter=lfs diff=lfs merge=lfs -text *.a filter=lfs diff=lfs merge=lfs -text *.param filter=lfs diff=lfs merge=lfs -text *.zip filter=lfs diff=lfs merge=lfs -text *.gz filter=lfs diff=lfs merge=lfs -text
同时可以看到我们二进制文件全部都转成了以下形式文本
version https://git-lfs.github.com/spec/v1 oid sha256:9171c8350d72ccca6ad60ac80b577157ad1f9fd44ca05744216e02ccbfcdf491 size 10260
确认无误，之后就可以推送到远端；
由于lfs的迁移会重写所有的commit，并且修改hash值，因此需要我们需要加上–froce
这步需要取消保护分支（保护分支无法-f）
git push --force --all
这样远程仓库的lfs迁移就完成了
git lfs pull
git reflog expire --expire-unreachable=now --all git gc --prune=now
lfs直观来讲更多的是针对仓库大clone慢的问题，我这边lfs迁移前后各备份各一个小型远程仓库做测试，
用的测试仓库二进制文件比较小，总大50m内，且变更次数也在个位数。
clone下来的仓库大小对比。
和我预估差不多，总的来说更适合二进制文件频繁变更，如果单纯是文件大，但文件不变更的话，在clone的时候区别不大，毕竟lfs在clone仍有下载源文件的步骤，除开下载，操作文件指针对git来说理论仍会有性能提升，但是可能感知不强。
推荐学习：《Git教程》
以上是十分钟学会GIT仓库瘦身及GIT LFS迁移说明的详细内容。更多信息请关注PHP中文网其他相关文章！
