Git LFS拉取速度极慢如何优化？是否适合存储大体积美术资源文件？

所有方案均无需使用命令行操作，可直接在 SourceTree 可视化配置中完成：

• 调整 LFS 并发下载数：在 SourceTree 的「设置」-「Git」面板中添加全局 Git 配置项 lfs.concurrenttransfers = 10，默认并发数仅为3，提升并发数后多文件批量拉取速度可提升3-5倍，适配你当前4000个文件的拉取场景。
• 配置 LFS 超时与增量拉取规则：添加全局配置项 lfs.activitytimeout = 60 避免网络波动导致的下载中断重传，同时可按项目需求配置 lfs.fetchinclude 规则，仅拉取当前工作目录需要的 LFS 资源，无需全仓拉取所有资源。
• 使用浅克隆减少拉取体积：首次克隆仓库时，在 SourceTree 克隆界面勾选 仅获取最新版本提交，不需要历史版本美术资源的情况下，拉取体积可缩减80%以上，大幅降低耗时。
• 关闭 SourceTree 额外校验功能：拉取前关闭 SourceTree 实时索引、自动校验文件哈希的非必要功能，减少拉取过程中的本地性能开销。

• 若你的美术资源需要和代码版本强绑定、有明确的版本回滚、分支同步需求，Git LFS 仍然是最优选择，完成上述优化后基本可以满足使用需求。
• 若美术资源仅做团队共享、无需和代码版本一一对应，也无需精细的版本追溯能力，可以替换为NAS、团队云盘等专用大文件存储方案，更适配大体积美术资源的批量传输场景。

内容的提问来源于stack exchange，提问作者Joost