Git LFS与普通Git对比：大文件存储相关技术问询

• 保持Git仓库轻量化：普通Git会把大文件的所有版本完整存入仓库，很快就会让仓库体积臃肿不堪；Git LFS只在仓库里存文件指针，实际大文件存在独立存储区，克隆、拉取仓库的速度会快很多。
• 提升Git操作效率：仓库体积小了，git clone、git pull、git push这些核心命令的执行速度大幅提升，不会因为大文件拖慢整个开发流程。
• 兼容原有Git工作流：不用切换到其他工具，依然能正常使用Git的分支、合并、提交等全套操作，团队协作的流程不需要做任何调整。
• 规范大文件版本管理：Git LFS会自动跟踪大文件的版本变更，和普通文件一样保留完整的历史记录，不会出现大文件版本丢失、混乱的情况。
• 降低仓库维护成本：体积小巧的仓库备份、迁移更方便，也能减少存储服务器的资源占用压力。

Git LFS本身没有内置的严格最大文件容量限制，实际能存储的文件大小上限主要取决于你使用的Git LFS服务器配置。比如GitHub的Git LFS服务默认单文件最大支持5GB，而自建的Git LFS服务器可以根据自身的存储资源调整这个限制。

• 额外的配置成本：需要先安装Git LFS客户端，还要在仓库中完成初始化配置，团队所有成员都得同步配置才能正常协作，增加了入门的门槛。
• 服务器兼容性有限：不是所有Git服务器都支持Git LFS功能，一些小众或自建的Git服务可能没有集成LFS，导致无法使用该功能。
• Git命令行为有变化：比如git checkout后需要额外执行git lfs pull才能获取实际的大文件，git fetch不会自动同步LFS对象，不熟悉操作的话容易出现文件缺失的问题。
• 可能产生额外费用：如果使用第三方Git LFS服务（如GitHub、GitLab），大文件的存储和流量可能会产生额外费用，文件越多、体积越大，成本越高。
• 离线工作受限制：如果无法连接到LFS服务器，就无法获取或提交大文件，对经常需要离线开发的场景不太友好。

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