在版本控制领域，Git已占据绝对统治地位二十年。这个几乎无处不在的工具，支撑着从个人项目到企业级单体仓库的开发流程。然而，世界已然改变，Git也需要为下一个十年做好准备。在FOSDEM 2026的演讲中，GitLab的Git团队负责人Patrick Steinhardt深入剖析了Git面临的几项核心挑战及其演进方向。
Git必须演进
Git的成功毋庸置疑，但它的设计烙上了2005年的时代印记。那时，SHA-1哈希算法被认为是安全的，Linux内核仓库被视为庞然大物，持续集成（CI）流程也非主流。如今，这些都已成为历史。SHA-1已被证明可被碰撞攻击，而像Chromium这样的现代单体仓库（Monorepo）规模远超当年。此外，Steinhardt坦率地指出，Git的用户体验从过去到现在都颇具挑战性。
Git的独特地位意味着它不能进行颠覆性的“革命”，而是必须平稳地“演进”，以免破坏数以千万计依赖它的项目和脚本。其演进主要聚焦在四个关键领域：哈希算法、引用存储、大文件处理和用户界面。
SHA-256：迫在眉睫的哈希迁移
Git的核心是内容寻址存储，每个对象（文件、目录树、提交）的身份都由其内容的哈希值决定。这个哈希值长期使用SHA-1算法生成。然而，自2017年SHA-1碰撞攻击被公开证实后，其安全性已不复存在。尽管破解需要巨大算力，但在AI驱动下算力暴涨的今天，这对于大型机构已非遥不可及。
Steinhardt指出，虽然Git本身不完全依赖SHA-1保证安全（还依赖GPG签名、HTTPS等），但整个生态系统——包括CI系统、各种脚本和工具——都默认SHA-1具有碰撞抗性。更重要的是，各国法规要求在2030年前淘汰SHA-1。因此，迁移势在必行。
Git项目已在2020年的2.29版本中引入了SHA-256支持，但生态系统的跟进缓慢。目前，仅有Git自身、Python实现的Dulwich以及Forgejo平台提供了完整支持。GitLab、go-git和libgit2提供了实验性支持，而包括GitHub在内的其他主流代码托管平台尚未支持。这形成了一个“先有鸡还是先有蛋”的困境。
为了打破僵局，Git计划在未来的3.0版本中将SHA-256设置为新建仓库的默认选项，以期倒逼生态适配。社区也可以助力，例如向喜爱的代码托管平台表达对SHA-256的关注，或在新项目中尝试使用SHA-256。对于从事开源开发的工程师而言，理解并推动这项基础架构的升级至关重要。
引用表（Reftable）：重构引用存储
Git的另一个重要演进是引用表。默认情况下，Git将每个引用（如分支、标签）存储为一个独立的文件。这种方式简单直观，但扩展性极差。当引用数量达到百万甚至千万级别时，文件系统的不区分大小写特性、大量小文件导致的存储浪费（每个文件可能占用4KB）、以及打包引用时巨大的重写开销，都成为严重瓶颈。
更棘手的是并发访问问题。Git最初并未为多用户同时读写设计，当一方写入引用而另一方读取时，可能得到新旧状态混合的非一致视图。
引用表作为一种新的二进制存储后端应运而生。它以更高效的格式存储引用，支持原子更新，并摆脱了文件系统对引用命名的限制。与SHA-256类似，引用表也计划在Git 3.0中成为默认设置。这意味着，任何通过直接操作文件系统来管理引用的脚本或服务端逻辑都需要调整，应改为通过标准的git命令来访问引用。
攻克大文件存储与传输难题
对于大多数开发者，引用扩展性问题或许还很遥远，但大文件带来的困扰却是实实在在的。Git最初为文本源代码设计，其压缩算法对二进制文件效果不佳，微小的改动就会产生全新的对象。克隆时默认下载全部历史，对于包含数百GB二进制资产的仓库来说是灾难，且克隆过程不支持断点续传。
代码托管平台更是苦不堪言。以GitLab为例，分析显示其75%的存储空间被大于1MB的二进制文件占用。这些数据无法像普通网站那样分流到CDN，必须由Git服务器直接提供，成为巨大的成本和性能瓶颈。
现有的Git LFS和部分克隆方案只是“创可贴”。真正的解决方案正在Git核心中构建：
- 大型对象承诺者（Large-object Promisor）：允许将大文件存储在独立的远程仓库（如支持S3 API的对象存储），与主仓库分离。客户端访问时无缝获取，而服务器端可将这些对象分流至CDN。该功能的初始协议已在Git 2.50中实现。
- 可插拔对象数据库：未来将为二进制文件引入专门的存储格式，使得增量更改只产生微小的存储开销，并与现有文本对象存储格式兼容。这需要对Git的存储层进行深度重构，相关工作已在Git 2.53中奠定了基础。
向竞争对手学习：用户界面改进
Git复杂的命令和晦涩的工作流一直备受诟病。新兴的、基于Rust开发的Jujutsu版本控制系统因其更现代、一致的体验而吸引了部分用户，这促使Git项目反思自身的用户界面。
Steinhardt分享了他对Jujutsu从排斥到欣赏的心路历程。Jujutsu的核心优势在于将历史视为可塑的“草稿”，而非“珍贵产物”。其默认可变的历史、自动更新的依赖项以及将冲突作为普通数据处理的理念，简化了许多高级工作流。
Git无法彻底重写UI，但可以借鉴这些优秀思想，增加一些“武断的子命令”来简化现代开发流程。例如，计划在Git 2.54中引入的git history split和git history reword命令，旨在让拆分提交、重写历史等操作变得像在Jujutsu中一样简单，从而改善处理堆叠分支等常见场景的体验。
社区的讨论与展望
演讲内容引发了技术社区的广泛讨论，一些观点补充了Git演进面临的细节挑战：
- 有开发者分享了其拆分提交的“土法”工作流，凸显了官方工具支持的必要性。
- 关于大文件，不仅有二进制文件，大文本文件（如日志、数据集）的存储效率也是问题。
- 引用表在提升性能的同时，也需考虑保留直接操作文件系统引用的灵活性，以满足某些特殊调试或恢复场景。
- 对于承诺者方案，用户关心使用
--mirror克隆的完整备份是否依然可靠，是否会因CDN数据丢失而失效。
Git的演进是一场平衡艺术，需要在提升性能、安全性与保持向后兼容、灵活性之间谨慎前行。从SHA-256的迁移、引用表和大文件处理等底层改进，到从Jujutsu等工具汲取灵感的用户体验优化，Git正系统地为其下一个十年夯实基础。对于整个开发生态系统而言，关注并参与这些变化，将有助于构建更健壮、高效的工作流。
参考资料
[1] LWN：为下一个十年演进 Git， 微信公众号：mp.weixin.qq.com/s/muP65QD17cUEDANLiJgwyQ
版权声明：本文由 云栈社区 整理发布，版权归原作者所有。
发表于 昨天 16:21
|
查看: 7|
回复: 0
