Git中大文件的未来就是Git本身
本文探讨了Git处理大型文件的演变趋势，指出传统的LFS（Git Large File Storage）方案存在性能瓶颈和复杂性，而Git本身正在通过改进的算法和存储机制来更好地支持大型文件。文章认为，未来的方向不是依赖外部扩展，而是让Git原生更高效地管理大型二进制文件和仓库，实现更简洁、统一的工作流程。
背景速读
- 长期以来，Git（分布式版本控制系统）在处理大文件时表现不佳，比如视频、数据集、设计稿或二进制文件。传统的解决方案是 Git LFS（Large File Storage，大文件存储扩展），它把大文件替换成指针，实际内容存到远程服务器上，但这带来了额外的复杂性和性能开销。
- 文章讨论的是 Git 自身（而不是通过 LFS 这类扩展）如何原生地解决大文件问题。核心思路是利用 Git 的新存储后端，比如 "bare object store"（裸对象存储），让 Git 能直接高效地管理大文件，而不需要 LFS 那一层绕路。
- 这背后的关键驱动因素是微软等公司——它们用 Git 管理 Windows 等巨型代码库（包含大量二进制文件），发现 LFS 不够用。微软主导了 Scalar（Git 性能优化工具）和 GVFS（已退役的大文件虚拟化方案）等项目，现在推动 Git 自身做出改进。
- 文章标题 "The future of large files in Git is Git" 的意思是：最终，大文件管理不应该依赖于独立扩展（如 LFS），而应该由 Git 本身的原生能力来解决，这是其路线图中的重要转变。