Git 3.0 即将问世：Git 用户需了解的下个重大版本信息

Git开发者正积极推进Git 3.0版本的开发工作，预计将于2026年底前发布。这将是自2014年Git 2.0发布以来首次重大版本升级。对于日常依赖Git的开发者而言，此次更新将带来影响版本控制底层机制的重大变革——您需要做好相应准备。
💬 78 条评论 | |

Git开发者正积极推进Git 3.0版本的开发工作，预计将于2026年底前发布。这将是自2014年Git 2.0发布以来首次重大版本升级。对于日常依赖Git的开发者而言，此次更新将带来影响版本控制底层机制的重大变革——您需要做好相应准备。

时间线：审慎推进策略

根据Git邮件列表讨论，开发者期望在2026年底前发布Git 3.0，但该时间表主要取决于外部因素。与常规小版本更新不同，Git 3.0作为里程碑版本，既允许项目引入破坏性变更，又为整个生态系统预留适应时间。

Git 3.0的发布规划允许项目实施破坏性变更，并通过文档和实验性构建向扩展的Git社区传达这些变更。

SHA-256：安全基石

Git 3.0最根本的变更在于将默认哈希算法从SHA-1切换为SHA-256，此举旨在解决持续多年的安全隐患。

元素周期表

变更缘由

Git自诞生起便采用SHA-1算法，但安全研究人员发现了该算法的缺陷，包括SHAttered攻击——该攻击成功演示了SHA-1哈希碰撞的实际可行性。尽管Git在2.13.0版本中采用了强化版SHA-1实现，但根本性弱点依然存在。

几乎主导了所有SHA-256相关工作的Brian m. carlson估计，此次迁移需要200-400个补丁，目前约完成100个。工作虽稳步推进，但让所有依赖项目支持SHA-256似乎是3.0版本发布的最大障碍。

对您的仓库意味着什么

SHA-256于2018年末被确立为SHA-1的继任者，Git 2.51.0版本将其设为Git 3.0的默认哈希算法。过渡计划包含SHA-1与SHA-256仓库间的互操作性，因此现有仓库不会立即失效。但团队最终仍需考虑迁移至 SHA-256 以提升安全性。

Rust 集成：内存安全机制引入 Git

作为重大架构变革，Git 3.0 将强制要求使用 Rust 进行构建。这对自 2005 年创建以来主要采用 C 语言开发的项目而言是重大转变。

Rust 路线图

Patrick Steinhardt提交的补丁系列引入可选Rust模块作为“试探性措施”，帮助用户和发行版适配新构建要求。文档明确指出自3.0版本起，Rust将成为构建Git的强制要求。

该计划分两步实施：首先通过Meson将Rust支持引入Git构建系统以确保集成一致性，随后在Git 3.0中强制要求使用Rust。

为何选择 Rust？

转向 Rust 带来多重优势：

  • 内存安全：Rust 的所有权与借用规则可消除其他项目中引发安全漏洞的整类缺陷
  • 现代化工具链：使 Git 与当前软件开发趋势保持同步
  • 长期可维护性：更易读的代码有助于吸引新贡献者

在Git引用表后端对Rust的早期实验已取得令人鼓舞的成果，代码可维护性得到提升，运行时错误显著减少。

平台考量

强制采用Rust可能限制Git的部署架构和平台范围，相较于当前的C语言代码。但此举旨在为发行版预留准备时间，确保工具链就绪。

引用表：性能飞跃式提升

Git 3.0 将默认采用“引用表”格式存储引用(分支与标签)，取代传统的“文件”后端。

性能提升

数据说明一切：在包含10,000个引用项的仓库中，相较传统格式，reftable后端使git-fetch操作性能提升22倍；git-push操作速度提升18倍。

实际应用效益

引用表格式解决了多个长期存在的问题：

它消除了Windows和macOS系统中不区分大小写的文件系统问题——在文件格式下，仅大小写不同的引用无法被存储。

删除引用不再需要重写完整的压缩引用文件，在大型仓库中这类文件可能达到数十兆甚至数千兆字节。

引用表后端在每次写入后执行几何压缩，确保后端始终处于良好维护状态，无需耗费资源进行整体重新打包。

重大变更与弃用项

Git 3.0 将清理部分历史遗留的不一致性：

git-whatchanged 命令(后继为 git log –raw)现要求用户显式使用 –i-still-use-this 标志，并已标记为将在 Git 3.0 中移除。

git-switch 和 git-restore 命令(在 Git 2.33.0 中引入以拆分 git-checkout 的双重功能)现已取消实验性标记。

Git 用户需知事项

对于使用 Git 的开发团队及个人开发者，Git 3.0 的变更在日常操作中基本不会产生影响：

短期内：

  • 现有仓库将保持正常运行
  • 过渡期间同时支持 SHA-1 和 SHA-256 仓库
  • 无需立即采取行动

展望未来：

  • 开始熟悉 SHA-256 相关概念
  • 关注 Git 托管服务商(GitHub、GitLab、Bitbucket 等)的 SHA-256 支持时间表
  • 考虑使用 Git 2.51+ 版本测试 reftable 格式优势
  • 若从源代码构建 Git，请确保基础设施满足 Rust 编译要求

性能优势：

  • 分支数量庞大的项目将显著提升拉取和推送操作速度
  • 复杂分支策略的仓库将因引用表格式获得更快的操作体验
  • 更优化的引用更新机制将提升工作流可靠性
  • 大型单仓库将尤其受益于性能提升

全局视角

Git正致力于在2026年推出3.0版本，该项目将解决SHA-256过渡、引入Rust语言及其他现代化改造工作。这标志着Git十余年来最重大的演进。

主导哈希算法过渡工作的Brian M. Carlson认为SHA-1已过时，而SHA-256能显著提升性能。此次转型不仅关乎安全性，更旨在为未来十年的软件开发构建更强大、更高效的版本控制系统。

为Git 3.0做好准备

尽管正式发布尚需一年多时间，现在正是着手准备的时机：

  1. 及时获取资讯：订阅Git邮件列表获取Git 3.0进展的官方更新
  2. 尽早测试：尝试Git 2.51+版本体验引用表性能提升
  3. 审查依赖项：确保工具链和托管平台已为支持SHA-256做好准备
  4. 更新文档： 着手规划如何向开发团队传达这些变更

前瞻展望

Git 3.0不仅是版本迭代，更是对安全性、性能与现代化的承诺。无论企业用户还是个人开发者，这些变革都将带来更高效的工作流程，并实现与现代开发工具的深度融合。

过渡期虽需适应调整，但Git项目正采取稳健策略确保兼容性，为生态系统预留适应时间。其带来的益处——通过 SHA-256 提升安全性、借助 reftable 优化性能、运用 Rust 增强代码安全性——使这次演进具有深远价值。

Git 的未来将比以往更快速、更安全、更强大。无论您维护的是小型个人项目还是管理庞大的单仓库，Git 3.0 的改进都将提升您的版本控制体验。

元素周期表抱枕

共有{78}条精彩评论

  1. 主版本号变更让我心慌。3.0会带来什么新功能？更重要的是，它会破坏哪些现有功能？

    回复

    1. git pull --rebase 现已成为默认行为。

      瞬间引发内战。

      回复

      1. 开发者是谁？我只想像个冷静理智的人一样交流。

        回复

            4. 据我所知当前Git维护者是Juno C Harmano，不是Linus。

              回复

            5. 因为Git 3.0尚未发布。Linus才是3.0版本的重大新特性

              回复

          2. 嘿，别给他技术建议！

            回复

      2. 请注意，某些人将自己的分支设为源头，这意味着在特定情况下可能将真实分支重新基准到他们的修改之上。

        回复

      3. 瞬间引发内战。

        为什么？

        “rebase”这个词似乎吓到很多人——我在教学时明确建议将其设为默认操作。

        这 不是 git rebase命令，后者当然存在诸多争议。

        回复

        1. 这不是git rebase命令，后者当然存在诸多争议。

          git pull --rebase实际上调用的是git rebase。

          怎么就不是git rebase？

          回复

          1. 它背后调用什么命令有什么关系？

            pull --rebase 不会对其他用户造成任何负面影响。它只会带来好处——减少无用的“Merged origin/XXX into XXX”合并提交。

            关于git rebase的激烈争论在于：你正在篡改他人可能已查看或构建其上的历史记录。

            回复

            1. 确实可能。若有人从你的分支创建子分支，从该分支拉取时可能遭遇超出预期的冲突。

              当然，使用rebase –onto可轻松解决，但操作就没那么简单了。

              回复

            2. 若真发生冲突，他们只需回滚操作，执行fetch后手动merge——根本无需rebase。

              回复

            3. git rebase本身并不意味着你已推送分支，更遑论他人可见的历史记录

              回复

  2. “十四个月后，某件事很可能会发生。”

    感谢提醒！我会记在日历上。

    回复

    1. 讨论的目的之一确实是提前告知更广泛的社区：不久的将来将迎来破坏性版本变更。

      回复

      2. 我说过要记进日历的！

        我还给自己写了升级脚本修复所有仓库：

        #!/bin/bash

find “$HOME” -type d -name “.git” -prune 2>/dev/null | while IFS= read -r GIT_DIR; do
    ( cd “$(dirname ”$GIT_DIR“)” && echo “升级当前目录...” && git upgrade-version 3.0 )
done
        回复

      3. 啊，看来他们要搞个Python 3式操作了——让整个行业浪费数亿美元时间，而这种事本来完全可以保持向后兼容来处理。

        回复

      1. 我这就去看看。我们有很多长期运行的分支，经常出现冲突。

        回复

        1. 也许它们跑累了就开始乱扔手？

          回复

  4. Git使用SHA1仅是为提交生成唯一ID。真有必要切换到SHA256吗？

    回复

    2. 没错。除了实际攻击风险，所有(更)受监管的行业都强制禁止使用SHA1。政府、银行、医疗、证券等领域皆然。大量企业类型虽未强制遵循这些标准。

      坦白说，开发者/系统管理员们早已厌倦这场讨论。

      回复

      1. 实在太累了…真的，真的太累了

        回复

  5. 我只想实现类似Mercurial的evolve功能

    回复

  6. 新版SHA在安全性方面真能发挥作用吗？任何哈希碰撞产生的都将是垃圾字节而非恶意代码。除非神明降临且宇宙逆天而为，否则精心设计的恶意软件根本不可能与合法Git哈希值产生碰撞。

    回复

    1. 漏洞利用机制并非如此运作，攻击者无需选择，而是会同时利用两种机制。这需要常规恶意软件配合垃圾字节制造碰撞——这种碰撞绝非“偶然发生”，而是人为制造的。算法升级的根本目的正是为了增加人为碰撞的生成难度。

      回复

      1. 看来我对sha哈希机制存在根本性误解。我原以为碰撞搜索者能期望的最佳结果仅是垃圾字节，且仅限垃圾字节。

        回复

        1. 你是先注入漏洞利用代码，再在注释区添加垃圾数据直到找到碰撞？

          回复

    2. 我更担心对象数据库和文件系统变更。Git本身没问题，但第三方支持跟进太慢

      回复

  7. 他们不能直接改名吗？

    Git听起来糟透了，而“British English”这个词本就形容讨厌的角色。

    回复

    1. 我觉得挺好。林纳斯不是用这个词自嘲吗？而且可能还挺贴切？

      回复

    2. 讨厌的角色

      我不知道🤔，感觉挺适合形容git的。想象它像《红矮星》里的里默(额头上贴着“G”字样)——简直是git的完美拟人化。

      我不是说该把他从剧里删掉…也不是说Git不是现今最棒的版本控制方案。就像《红矮星》一样它很受欢迎。但天啊，Git绝对是我学过的最任性、最挑剔、最苛刻、最刺头、最不友好的版本控制工具。它和马桶圈一样难搞。其他版本控制系统会牵着你的手引导操作，用友善方式欢迎你。而Git却在你眼前直接吐屎，瞪着你的眼睛说“你心知肚明”……可你根本不懂！到底犯了什么错？为什么Git如此暴躁？！它在吞噬我的作业啊！！我亲眼见过它逼得开发者泪流满面。

      但Git就像《太空堡垒》里的里默，不知怎的……最终你会慢慢接受它。把它当作船员中的怪咖之一，学会应对它的古怪脾气。甚至某天，或许你会承认自己竟有点喜欢这个明显讨厌的角色。不过这纯粹是斯德哥尔摩综合症罢了。不过你会认真向菜鸟们解释：这分明是他们自己的错，然后手把手教他们如何清理Git留下的烂摊子(还得用特定方式操作以免激怒Git——毕竟地毯上的粪便还算轻的，它能干的糟心事多着呢)

      (顺便说句真心话，我确实爱 Git ，但老实讲它确实偶尔像个混蛋)

      回复

      1. 哈哈，写得真棒。读得很过瘾。

        回复

  8. 我永远不会用git-rust。

    希望出现一个无Git的Rust替代方案。

    回复

    1. 你是Git源代码贡献者却不愿写Rust？还是说Rust作为终端用户影响了你？Rust只是门语言而已。

      回复

      1. 突发新闻：受变革影响最小的群体最热衷于推动变革。

        回复

      1. 鉴于当前除contrib/目录外似乎不存在Rust代码，唯一合理的结论是：纯粹出于意识形态原因。

        回复

        1. 就像有人因为钉子是用钉枪而非锤子钉的就不愿使用椅子。语言是工具。只要能达成相同目标，方式并不重要。

          回复

          1. 若为此需绕更多弯路，那便另当别论。眼下看来，我们似乎要承受两全其美的最坏结果。

            回复

      2. 摘自Git文档(重点标注为本人添加)：

        Git将强制要求Rust作为 构建流程的组成部分 。虽然Git 2.49已开始采用Rust，但目前所有Rust组件均为可选。

        所以除非他们真从源代码编译而非直接安装deb/rpm包，否则抱怨纯属无稽之谈。

        回复

  9. 把Rust硬塞给所有人的计划还在执行？看来我得被迫从Git转用Got了。

    回复

    1. 作为Git用户，我很好奇这会对你产生什么影响？

      回复

      1. 例如Rust在OpenBSD ppc和Darwin ppc上完全无法运行，这意味着我根本无法在这些平台安装任何依赖它的软件。

        回复

        1. 无法安装任何需要Rust的软件

          根据Git文档(强调为本人添加)：

          Git将强制要求Rust作为 构建流程的组成部分 。虽然Git从2.49版开始采用Rust，但目前所有Rust编写的组件均为可选。

          回复

          1. 只要Rust组件保持可选状态，这并非灾难(但若Rust取代C语言，此前可用的可选组件将失效)。若Git构建本身必须依赖Rust，那么Rust无法正常运行的平台将无法使用Git。

            回复

        2. Rust会编译为机器码。使用Rust编写的应用程序时，无需安装任何Rust相关组件。

          回复

          1. Rust会编译成机器码

            没错，但你需要一个可用的编译器目标。powerpc-unknown-openbsd和powerpc64-unknown-openbsd属于三级目标，根据Rust文档说明这意味着

            可能工作也可能不工作

            至于powerpc*-darwin，似乎连目标都不存在。

            回复

            1. 确实不存在。我已在 mrustc 中添加该目标，但 Rust 自身尚未支持，且近期 LLVM 存在缺陷，因此我们需要在 rustc 中集成 gcc 代码生成器或使用 gccrs。

              回复

          2. 若编译器本身存在缺陷，则无法编译任何内容。缺少目标架构和ABI支持，交叉编译同样无法实现。这可能在以下任一情况解决：a) gccrs成为rustc的完整替代方案，或b) rustc的gcc后端正常工作并支持ABI，使rustc能通过mrustc和gcc进行引导编译。据我所知，这两种情况短期内都不太可能实现。

            回复

      2. 作为普通用户或许不会，但我们运行着自带公司内部扩展的Git分支，因此希望看到让构建系统复杂化的充分理由。

        需要澄清的是，我并非反对Rust语言本身。公司内部已开展多个实验项目，尝试用Rust替代旧工具，以探索其适用场景和最佳实践。但坦率说，Rust的生态系统让人感觉像是回到了Python 2.3时代。

        回复

        1. 这确实是个合理顾虑，但我感觉大多数在Git中抵触Rust的人并非处于相同处境。好奇的是，你们不能使用libgit2或gitoxide吗？或者既然能共享代码，为何需要自建分支？

          回复

          1. 运行自定义分支的决定在我入职前就已确定，因此我并不清楚具体缘由。我知道部分工作已提交上游，但仍有部分留存于公司内部，主要涉及代码审查流程。

            迄今为止，所有尝试转向GitLab等无特定客户端限制的模型的努力，都遭到了资深开发者的阻挠。我也无法解释原因，因为除了“我们不喜欢网页界面”之外，我尚未听到其他合理解释。

            回复

            1. 正因如此，我开始整理“技术决策”文档，并在分支的README中记录决策缘由。这样当有人质疑“为何不用通用方案”时，我能查阅依据，同时可重新审视已失效的决策。

              不过你可能需要为“管理层强行通过的荒谬决策”准备个暗号…

              回复

            2. 说实话管理层可能压根不知情，他们对公司软件开发环节的认知极其有限 🙂

              更像是开发者各行其是，既无视新人意见(比如“你才干了8年，我干了30年肯定对”)，也排斥任何使用年限不足十年的技术。

              Systemd？“这是魔鬼的产物，永远不该用！”

              Gitea/Forge/Gitlab 之类？“我不喜欢人们能自助解决问题，不如用可能失效的定时任务分担这些功能，再确保只有特定人员能修复，这样他们才能保持重要性”

              人人可用的完善IT基础设施？“对我够用了，你用不好我才不管，而且我会阻挠任何变更——毕竟这会让我显得不那么重要”

              需要确定性构建？“在我机器上能编译成功，管它在别人机器上行不行？”

              需要构建服务器运行规范文档？"何必？反正能用就行，谁愿意把服务器上的黑科技写成文档？我们永远不升级任何东西，这样就没事了"

              说实话，微软终止Windows 10支持是促使我们整理文档并升级的关键因素之一——因为管理层强制要求。开发者本身要么缺乏兴趣，要么被老开发者压制，要么根本不具备能力。

              回复

          2. 顺便提一句，整个Rust项目源于有人想将Rust集成到xdiff中——这个Git的diff引擎很久以前就从另一个项目分叉而来。XDiff本身采用LGPL许可，而非Git自身的GPL许可，这使得它能更轻松地融入其他项目。

            例如，libgit2维护的Git xdiff分支版本可直接作为LGPL库使用。Vim的diff模式同样采用Git xdiff作为内部差异引擎。

            引入Rust意味着所有下游项目也将受到影响。诚然，项目应自主决策，但至少应当意识到下游影响。

            回复

    2. 对Junio等人有益的事，对我也有益。

      回复

    3. 真心不明白为何这么多人关心这事

      回复

      1. 因为这意味着Rust出问题的地方，Git也会跟着崩溃。

        回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的：