Git 功能发展历史
目录
- Git 的诞生与设计哲学
- 2005—2008：从原型到 1.0 的奠基期
- Git 1.5—1.9：基础功能完善期
- Git 2.0：里程碑式的行为变更
- Git 2.1—2.22：渐进式改进与体验优化
- Git 2.23：
switch与restore的引入 - Git 2.24—2.29：Partial Clone、Sparse Checkout 与 SHA-256 实验
- Git 2.30—2.37：性能优化与 Sparse Index
- Git 2.38：Scalar 集成与超大规模仓库支持
- Git 2.39—2.47：持续优化与新工具
- 主要安全问题与处理
- 总结与展望
1. Git 的诞生与设计哲学
1.1 诞生背景
2005 年 4 月 7 日，Linus Torvalds 在 Linux 内核社区因 BitKeeper 商业版本控制工具授权争议而被迫寻找替代方案时，提交了 Git 的第一个 commit（e83c5163316f894fb6db，“Initial revision of ‘git’, the information manager from hell”）。Git 的诞生并非偶然，而是 Linux 内核开发模式对分布式、高性能、强完整性版本控制工具的迫切需求所催生的产物。在 BitKeeper 撤回免费许可后，内核社区曾短暂使用过 Monotone 等工具，但它们在处理内核这种规模（当时已有数万个文件、上百名核心开发者）时性能表现不佳，这促使 Torvalds 决定从零开始设计一个全新的系统。
Torvalds 在设计 Git 时提出了三个核心目标：速度（Speed）、简单性（Simplicity）、以及强完整性（Strong integrity against corruption）。他曾在邮件列表中明确表示，Git 的设计灵感部分来源于 Monotone，但完全摒弃了其基于数据库的实现方式，转而采用基于内容寻址（content-addressable）的扁平对象数据库。这种设计使得 Git 在处理大规模代码库时具有近乎恒定时间的查找性能，并通过 SHA-1 哈希为每个对象提供天然的完整性校验。Git 的第一个公开版本（1.0 之前）于 2005 年 7 月发布，仅包含最核心的 init-db、update-cache、write-tree、commit-tree 等底层命令，用户接口还相当原始。
1.2 设计哲学对后续版本演进的深远影响
Git 的核心数据模型——blob、tree、commit、tag 四类对象——自诞生之日起就未曾改变，这为后续二十年的功能扩展提供了稳定的根基。所有后续版本中新增的高级命令（如 git switch、git restore、git sparse-checkout）本质上都是对底层 plumbing 命令的封装与重组。这种"底层稳定、上层演进"的设计哲学，使得 Git 能够在不破坏既有仓库兼容性的前提下持续引入新功能。例如，2017 年 SHA-1 碰撞攻击（SHAttered）曝光后，Git 社区能够通过引入 sha1dc（碰撞检测哈希）平滑过渡，而无需立即重写整个对象模型；同样，2020 年开始的 SHA-256 迁移工作也是建立在原有数据模型之上的扩展。
从用户视角看，这种设计哲学带来两个显著影响：第一，用户学习曲线虽然陡峭（需要理解暂存区、分支指针等概念），但一旦掌握，新版本的功能学习成本极低；第二，旧仓库在新版本 Git 中始终可用，向后兼容性极佳。这也是为什么许多企业能够运行十年前的仓库而无需迁移。理解这一哲学，有助于用户在面对 Git 不断演进的功能时，把握"哪些是核心不变量、哪些是表层便利"的边界。
2. 2005—2008：从原型到 1.0 的奠基期
2.1 早期命令体系的形成
Git 1.0 之前的版本（0.99 系列）命令命名相当底层且不直观，例如 update-cache（后改为 add）、cat-file、ls-tree、read-tree、write-tree、commit-tree 等。这些命令直接操作对象数据库，对普通用户极不友好。2005 年下半年，Junio Hamano 接替 Torvalds 成为 Git 的维护者（Torvalds 转向继续维护 Linux 内核），他主导了 Git 用户接口的全面重构。Hamano 引入了 git 作为统一入口的"porcelain"（瓷器层）命令体系，将原本零散的底层命令封装为 git add、git commit、git log、git diff 等更符合直觉的高层命令，这一架构延续至今。
这一时期最重要的用户可见变化是 git pull 与 git push 的引入，它们封装了 fetch + merge 和 send-pack + receive-pack 的组合操作，使分布式协作成为可能。同时，git clone 命令的出现让用户能够一键复制远程仓库的全部历史，这是 Git 相对于集中式版本控制系统（如 CVS、SVN）最显著的体验优势之一。2005 年 12 月发布的 0.99.9 版本已经具备了现代 Git 的基本骨架，包括分支（branch）、标签（tag）、合并（merge）等核心概念。
2.2 Git 1.0 与 1.1—1.4 的稳定化
2005 年 12 月，Git 1.0 正式发布，标志着项目从快速原型阶段进入稳定维护阶段。1.0 版本确立了 Git 的版本号策略：偶数次的次要版本号（如 1.0、1.2、1.4）为稳定版，奇数次（如 1.1、1.3）为开发版，这一策略一直延续到 2.0 之后改为时间驱动的定期发布。1.0 版本中，git revert、git reset、git tag 等常用命令已经成型，gitk 图形化历史浏览器也作为 contrib 工具加入。
Git 1.1 至 1.4 系列（2006—2006 年）主要工作是性能优化与功能补全。1.3 版本引入了 git rebase，这是 Git 工作流中与 merge 并列的核心操作，允许用户将本地提交"重放"到另一分支之上，从而保持线性历史。1.4 版本引入了 git format-patch 和 git am，为邮件列表协作模式（Linux 内核的典型工作流）提供了标准化工具。这一时期还引入了 git submodule 的雏形，允许在一个仓库中嵌套引用另一个仓库，尽管该功能在后续多年中一直因易用性问题被诟病。1.5 版本之前，Git 的安装与配置仍然较为复杂，Windows 平台支持几乎为零，这限制了它在非 Linux 社区的普及。
3. Git 1.5—1.9：基础功能完善期
3.1 Git 1.5：远程分支模型的确立
2007 年 2 月发布的 Git 1.5 是用户接口演进中一个极为重要的版本。在此之前，远程分支以 origin 分支的形式直接存在于本地分支命名空间中，用户容易混淆本地分支与远程跟踪分支。1.5 版本引入了 refs/remotes/ 命名空间，将远程跟踪分支明确隔离到 origin/master 这样的路径下，并引入了 git remote 命令用于管理远程仓库配置。这一变更使得 git branch -r 能够清晰列出所有远程分支，git checkout origin/feature 可以查看远程分支内容而不创建本地分支，极大降低了分布式协作的认知负担。
1.5 版本还引入了 git stash 命令，允许用户临时保存工作区与暂存区的修改，以便切换分支处理紧急任务后再恢复。这一功能迅速成为 Git 用户最常用的命令之一，解决了"工作到一半需要切换分支"这一高频痛点。同时，git submodule 命令正式成型，git mergetool 提供了调用外部三方合并工具（如 meld、kdiff3、vimdiff）的统一接口。1.5 版本的发布标志着 Git 从"内核开发者的专用工具"开始向"通用版本控制系统"转型，其用户友好性有了质的提升。
3.2 Git 1.6—1.7：配置体系与工作流优化
Git 1.6（2008 年 8 月）引入了 git config 的全局配置文件 ~/.gitconfig 与仓库级 .git/config 的分层体系，确立了 system/global/local 三级配置覆盖规则。这一版本还开始统一命令命名风格，将原本带连字符的命令（如 git-add、git-commit）整合为 git add、git commit 的子命令形式，并逐步淘汰旧的 dash 形式。1.6 版本引入了 git bisect 的可视化改进，以及 git blame 的性能优化，使得在大型仓库中追溯代码历史成为日常可行操作。
Git 1.7（2010 年 2 月）系列是功能演进的高产期。1.7.0 引入了 git checkout -- 用于丢弃工作区修改的简写形式，以及 git merge --no-ff 强制保留合并提交的选项，后者成为团队协作中保留特性分支历史的标准做法。1.7.4 引入了 git push --force-with-lease，相比 --force 更安全——它会检查远程分支是否被他人更新，避免覆盖他人的提交。这一命令至今仍是团队协作中处理 rebase 后推送的推荐方式。1.7.5 改进了 git rebase -i（交互式 rebase）的体验，使其成为整理提交历史的利器。1.7.9 引入了 git merge --no-edit 与 GPG 签名提交支持（git commit -S），为安全敏感项目提供了提交身份验证机制。
3.3 Git 1.8—1.9：成熟期的细节打磨
Git 1.8（2012 年 10 月）引入了 git submodule absorbgitdirs，改善了子模块的目录布局问题；git rebase --autostash 自动在 rebase 前 stash、rebase 后 pop，免去了手动切换分支的繁琐。1.8 版本还引入了 git branch --set-upstream-to 替代了原 --set-upstream（后者因参数顺序易混淆被弃用），并改进了 git log --graph 的可视化输出。1.8.2 引入了 .gitattributes 中的 export-ignore 等属性，方便在 git archive 时排除特定文件。
Git 1.9（2014 年 2 月）是 1.x 系列的最后一个主要版本。它引入了 git clone --reference 的改进、git log -L 用于追踪单行或行范围的演变历史（line-level history），以及 git push --follow-tags 在推送提交时一并推送相关标签。1.9 版本还大幅改进了 git fetch --depth 与 git clone --shallow 的浅克隆功能，为后续 partial clone 的引入埋下伏笔。1.9 之后，Git 项目宣布进入 2.0 周期，标志着 Git 在功能成熟度上进入了一个新阶段。
4. Git 2.0：里程碑式的行为变更
4.1 push.default 从 matching 改为 simple
Git 2.0 于 2014 年 6 月发布，是 Git 历史上最具用户可见影响的主版本号变更。最核心的变化是 push.default 配置项的默认值从 matching 改为 simple。在 1.x 时代，matching 模式下执行 git push 不带参数时，会将所有与远程分支同名的本地分支一并推送，这在多分支并行开发时极易造成意外推送——例如用户在本地实验性分支上的提交可能被无意推送到远程，影响他人或触发 CI。simple 模式则只推送当前分支到同名的远程分支，且要求本地分支必须已设置上游跟踪关系，行为更可预测、更安全。
这一变更虽然在 1.x 后期版本中已通过警告提示用户迁移，但在 2.0 正式生效时仍引发了大量讨论。对于长期使用 matching 模式的老用户，升级后会发现 git push 不再推送所有分支，需要显式指定分支名或调整配置。从用户视角看，这一变化体现了 Git 社区对"安全默认值"理念的重视——宁可让用户多敲几个字符，也不应让默认行为产生不可逆的副作用。这一理念在后续版本中持续贯彻，例如 2.0 同时将 git add -u（仅更新已跟踪文件）的行为明确化，避免与 git add .（包括新文件）混淆。
4.2 其他重要变更
Git 2.0 还引入了一系列其他改进。git rebase 默认使用 --fork-point 检测被 rebase 分支的真正基点，避免在远程跟踪分支被 rebase 后误合并旧提交。git push 引入了 --force-with-lease 的进一步改进。git log 与 git rev-list 引入了 --no-walk 等选项用于精确控制遍历行为。在协议层面，2.0 开始为后续的 v2 协议（2018 年引入）做准备，改进了 smart HTTP 与 SSH 协议的效率。
对于从 1.9 升级的用户，2.0 的迁移成本主要在于 push.default 的行为变化。官方建议用户在升级前显式设置 git config --global push.default simple（或 current、upstream 等其他模式）以明确意图，避免依赖默认值。这一版本也标志着 Git 进入"以用户体验为导向"的演进阶段，后续的 2.x 系列在保持向后兼容的同时，持续优化常用命令的输出、错误提示与默认行为。
5. Git 2.1—2.22：渐进式改进与体验优化
5.1 Git 2.1—2.12：体验优化与协议改进
Git 2.1（2014 年 8 月）引入了 git log --oneline 在终端自动启用颜色、git config --edit 的改进，以及 git rebase -i 中 exec 命令的增强。2.2（2015 年 11 月）引入了 git worktree 命令（当时为实验性），允许在同一仓库下创建多个工作目录，每个工作目录可以检出不同的分支——这对于需要同时处理多个分支（如修复线上 bug 同时开发新功能）的用户是巨大便利，避免了反复 stash 与切换。2.3（2015 年 2 月）引入了 git push --follow-tags 的稳定化与 git config push.followTags 配置项。
Git 2.4（2015 年 4 月）将 git worktree 从实验性转为稳定，并引入了 git rebase --interactive 的 --rebase-merges 选项（保留合并提交的 rebase）。2.5（2015 年 7 月）引入了 git worktree add --lock 与 git fast-export/git fast-import 的改进。2.6（2015 年 9 月）引入了 git rebase -i 的 --autostash 默认配置项。2.7（2016 年 1 月）改进了 git tag 的排序与 git for-each-ref 的格式化能力。2.8（2016 年 3 月）引入了 git rebase --gpg-sign 与 git push --signed。
Git 2.9（2016 年 6 月）引入了 git rebase 默认启用 --fork-point、git config diff.indentHeuristic 改进 diff 输出的可读性。2.10（2016 年 9 月）引入了 git config core.sshCommand 用于指定 SSH 客户端。2.11（2016 年 11 月）引入了 git rebase -i 的 --exec 改进与 git diff --indent-heuristic。2.12（2017 年 2 月）引入了 git config core.commitGraph 的雏形与 git rebase 的 --rebase-merges 稳定化。这一阶段，Git 的功能演进以"打磨细节、提升性能"为主，没有颠覆性的新概念引入。
5.2 Git 2.13—2.22：安全加固与协议升级
Git 2.13（2017 年 5 月）是一个安全敏感版本。它修复了 git shell 中的一个漏洞（CVE-2017-8386），该漏洞允许不受信任的 Git 用户在远程主机上执行 shell 命令。同时，2.13 引入了 git config core.hooksPath 允许将 hooks 集中存放在仓库外的目录，便于团队共享 hooks 配置而不污染仓库。2.13 还引入了 git submodule 的递归操作改进与 git diff --submodule 的优化。
Git 2.14（2017 年 8 月）引入了实验性的 protocol v2（协议 v2），显著减少了 git fetch/ls-remote 的数据传输量，对于大型仓库与低带宽环境改善明显。2.15（2017 年 10 月）引入了 git config core.usereplacerefs 与 git rebase 的 --rebase-merges 进一步完善。2.16（2018 年 1 月）引入了 git config protocol.version 配置项允许用户选择协议版本。2.17（2018 年 4 月）引入了 git rebase 的 --rebase-merges 默认行为改进与 git config pack.useSparse。
Git 2.18（2018 年 6 月）正式将 protocol v2 作为可选项（通过 git config protocol.version=2 启用），并引入了 git config grep.fallbackToNoIndex。2.19（2018 年 9 月）引入了 git config feature.experimental 用于启用实验性优化、git rebase 的 --rebase-merges 默认启用。2.20（2018 年 12 月）引入了 git rebase 的 --rebase-merges 稳定化与 git config rebase.backend。2.21（2019 年 2 月）引入了 git config feature.manyFiles 针对大型仓库的预设优化。2.22（2019 年 6 月）引入了 git config protocol.version=2 作为默认值（在支持的远程上），标志着 protocol v2 的全面落地，并引入了 git rebase 的 --rebase-merges 进一步改进与 git config pack.useSparse 的稳定化。
6. Git 2.23：switch 与 restore 的引入
6.1 git checkout 的职责拆分
Git 2.23（2019 年 8 月）是用户接口演进中一个标志性的版本。它引入了两个新命令：git switch 与 git restore，旨在拆分 git checkout 这一长期承担过多职责的"瑞士军刀"命令。git checkout 在历史上同时承担了三类操作：切换/创建分支（git checkout branch、git checkout -b new-branch）、恢复工作区文件（git checkout -- file）、以及检出远程分支或特定提交（git checkout origin/feature、git checkout <commit>）。这种多功能性虽然灵活，但对新手极不友好——同一个命令根据参数不同行为差异巨大，错误提示也容易令人困惑。
git switch 专门负责分支切换与创建：git switch feature 切换到 feature 分支，git switch -c new-branch 创建并切换，git switch - 切回上一个分支。git restore 专门负责恢复工作区文件：git restore file 丢弃工作区修改（等价于 git checkout -- file），git restore --staged file 将文件从暂存区移除但保留工作区修改（等价于 git reset HEAD file），git restore --source=HEAD~3 file 从指定提交恢复文件。这种职责拆分使得每个命令的语义清晰单一，错误提示也更精准——例如 git switch file 会直接报错而非像 git checkout file 那样可能产生意外行为。
6.2 迁移与兼容性
git switch 与 git restore 在 2.23 中标记为"实验性"（experimental），但功能已基本完整。git checkout 命令并未被弃用，仍完全可用，这保证了现有脚本与教程的兼容性。官方建议新用户优先学习 switch/restore，而老用户可按需迁移。从用户视角看，这一变更体现了 Git 社区对"命令语义清晰性"的重视——宁可引入新命令增加学习成本，也不应让单一命令承担过多职责。后续版本中，switch 与 restore 逐步稳定，到 2.27 左右已不再标记为实验性，成为推荐用法。
这一版本还引入了 git config checkout.defaultRemote 用于在多远程环境下指定默认推送远程，以及 git rebase 的 --rebase-merges 进一步改进。2.23 的发布标志着 Git 用户接口进入"精细化设计"阶段，后续版本（如 2.25 的 sparse-checkout 子命令化、2.29 的 maintenance 子命令化）延续了这一思路，将原本零散的配置项整合为语义清晰的命令组。
7. Git 2.24—2.29：Partial Clone、Sparse Checkout 与 SHA-256 实验
7.1 Git 2.24—2.26：Partial Clone 与 Sparse Checkout 子命令化
Git 2.24（2019 年 11 月）将 partial clone（部分克隆）从实验性转为可用状态。Partial clone 允许用户在克隆时只下载部分对象（如只下载 commit 与 tree，不下载 blob），其余对象在后续 git checkout/git cat-file 时按需拉取。这对于超大型仓库（如 Chrome、Android）的克隆体验改善巨大——原本可能需要数小时下载几十 GB 的仓库，现在可以在数分钟内完成"骨架"克隆，开始浏览历史与代码结构。git clone --filter=blob:none 是最常用的形式，配合 --filter=tree:0 可进一步减少传输量。
Git 2.25（2020 年 1 月）将 git sparse-checkout 从底层配置项升级为完整子命令，引入了 git sparse-checkout init、set、disable 等子命令，并引入了"cone mode"（锥形模式）简化稀疏检出模式的编写。在 cone mode 之前，sparse-checkout 使用 .git/info/sparse-checkout 文件中的 gitignore 风格模式，对新手不友好且性能较差；cone mode 限制为目录级别的包含/排除，但性能显著提升且模式更易理解。git sparse-checkout set --cone src docs 即可只检出 src/ 与 docs/ 目录。
Git 2.26（2020 年 3 月）引入了 git config core.commitGraph 的稳定化与 git config gc.writeCommitGraph 默认启用，commit-graph 文件加速了 git log --oneline、git tag --contains 等历史遍历操作。2.26 还引入了 git maintenance 命令的雏形（当时为 git gc --auto 的改进），以及 git config feature.manyFiles 的进一步优化。
7.2 Git 2.27—2.29：maintenance 子命令与 SHA-256 实验
Git 2.27（2020 年 6 月）引入了 git maintenance 子命令，将原本分散的 git gc、git prune、git repack、git commit-graph write 等维护操作整合为统一的 git maintenance run、git maintenance start、git maintenance stop 接口，并支持通过 --schedule 配置定时任务（需配合系统 cron 或 launchd）。这一改进使得仓库维护从"手动执行零散命令"升级为"声明式定时任务"，对于大型仓库的长期健康维护意义重大。
Git 2.28（2020 年 7 月）引入了 git config init.defaultBranch 配置项，允许用户自定义 git init 创建的默认分支名（默认仍为 master，但社区开始讨论向 main 迁移）。2.28 还改进了 sparse-checkout 的 cone mode 性能与 partial clone 的对象按需拉取机制。2.29（2020 年 10 月）引入了实验性的 SHA-256 仓库支持——git init --object-format=sha256 可创建使用 SHA-256 哈希的仓库，这是 Git 应对 SHA-1 长期安全风险的关键一步。虽然 SHA-256 仓库与 SHA-1 仓库之间尚不能直接互操作（迁移工具在后续版本逐步完善），但 2.29 标志着 Git 正式启动了哈希算法迁移的长征。
8. Git 2.30—2.37：性能优化与 Sparse Index
8.1 Git 2.30—2.34：协议、性能与安全
Git 2.30（2020 年 12 月）引入了 git config init.defaultBranch 的进一步讨论与 git maintenance 的稳定化。2.30 还改进了 git rebase 的 --rebase-merges 与 git rebase --update-refs（实验性，自动 rebase 依赖的分支）。2.31（2021 年 3 月）引入了 git config pack.useSparse 的稳定化与 git multi-pack-index 的改进。2.32（2021 年 6 月）引入了 git config feature.manyFiles 的进一步优化与 git sparse-checkout 的 cone mode 性能改进。
Git 2.33（2021 年 8 月）引入了 git rebase --update-refs 的稳定化，这一功能对于在特性分支链（branch chain）上工作的用户极为有用——当 rebase 一个基础分支时，依赖它的下游分支会自动跟随 rebase，无需手动逐个处理。2.33 还引入了 git config pack.useBitmaps 的改进与 git config index.threads 的优化。2.34（2021 年 11 月）引入了 git config feature.manyFiles 的进一步优化、git rebase 的 --empty=drop 等选项，以及 git sparse-checkout 的 sparse-index 实验性支持。
8.2 Git 2.35—2.37：Sparse Index 与大型仓库支持
Git 2.35（2022 年 1 月）引入了 git config index.sparse 的稳定化与 sparse-index 的进一步改进。Sparse index 是 sparse-checkout 的性能优化——在传统实现中，即使启用了 sparse-checkout，Git 的索引文件仍记录所有文件（包括未检出的），导致索引文件庞大、操作缓慢；sparse index 将索引压缩为只记录稀疏检出范围内的文件，对于超大型仓库（如 Windows 代码库的 300 万文件）性能提升数倍。2.35 还引入了 git config core.fsmonitor 的改进（文件系统监控守护进程）。
Git 2.36（2022 年 4 月）引入了 git config feature.manyFiles 的进一步优化、git sparse-checkout 的 sparse-index 默认启用（在 cone mode 下），以及 git rebase 的 --rebase-merges 改进。2.36 还引入了 git config safe.directory 安全机制——在 CVE-2022-24765 修复后，Git 拒绝在所有权不属于当前用户的仓库目录中执行操作，safe.directory 配置项允许用户显式信任特定目录。2.37（2022 年 7 月）引入了 git rebase --empty=keep 等选项、git config credential.helper 的改进，以及 sparse-index 的进一步性能优化。
9. Git 2.38：Scalar 集成与超大规模仓库支持
9.1 Scalar 的引入
Git 2.38（2022 年 10 月）是一个对超大规模仓库用户意义重大的版本。它将 Microsoft 开发的 Scalar 工具集成到 Git 主线（作为 git scalar 子命令）。Scalar 最初是微软为应对 Windows 代码库（约 300 万文件、500GB+ 仓库大小）而开发的"Git 配置增强器"，它本身不修改 Git 的核心代码，而是通过自动启用一系列性能优化配置（commit-graph、multi-pack-index、sparse-checkout、partial clone、fsmonitor、scheduled maintenance 等）来让 Git 在超大规模仓库下保持可用。
git scalar clone <url> 会执行一个优化过的克隆流程：先 blobless clone（只下载 commit 与 tree），然后启用 sparse-checkout（cone mode，默认只检出根目录），再启用 fsmonitor 与 scheduled maintenance。对于普通用户，git scalar register 可以将现有仓库注册到 Scalar 的优化配置中。Scalar 的集成标志着 Git 社区正式承认"超大规模仓库"是一个需要专门支持的场景，而非通过用户自行调优配置解决。
9.2 其他重要改进
Git 2.38 还引入了 git rm 对 sparse-index 的感知改进、git rev-list --disk-usage=human 的人类可读磁盘占用统计，以及 git for-each-ref 的 --merged/--no-merged 选项。在协议层面，2.38 改进了 protocol v2 的效率。对于普通用户，2.38 的日常体验变化不大，但对于在大型 monorepo 中工作的开发者，Scalar 的引入使得"克隆一个 100GB 仓库并在数分钟内开始工作"成为可能，这是 Git 在企业级场景中与 Perforce、Plastic SCM 等专用大型仓库系统竞争的关键能力。
10. Git 2.39—2.47：持续优化与新工具
10.1 Git 2.39—2.43：维护、合并与配置改进
Git 2.39（2022 年 12 月）引入了 git maintenance 的进一步改进与 git config 的 --show-origin 增强。2.39 还引入了 git rebase 的 --rebase-merges 改进与 git config core.fsmonitor 的稳定化。2.40（2023 年 3 月）引入了 git merge --merge-base 选项允许指定合并基点、git bisect 的内置实现（不再依赖 shell 脚本，性能与可维护性提升）、git jump 工具的 Emacs 支持，以及 git cat-file 的性能改进。2.40 是一个贡献者数量创纪录的版本（88 位贡献者，30 位新人），体现了 Git 社区的活跃度。
Git 2.41（2023 年 6 月）引入了 git config 的进一步改进、git rebase 的 --rebase-merges 优化，以及 git cat-file 的批处理性能提升。2.41 同样贡献者众多（95 位，29 位新人）。2.42（2023 年 8 月）引入了 git config 的 --fixed-value 选项用于精确匹配配置值、git rebase 的改进，以及 git sparse-checkout 的进一步优化。2.43（2023 年 11 月）引入了 git config 的 --default 选项、git rebase 的 --rebase-merges 改进，以及 git for-each-ref 的格式化能力增强。
10.2 Git 2.44—2.47：参考后端与多包索引
Git 2.44（2024 年 2 月）引入了 git config 的进一步改进、git rebase 的优化，以及 reftable 后端的实验性支持。Reftable 是一种新的引用存储格式，相比传统的松散引用文件（每个分支/标签一个文件）与 packed-refs 文件，reftable 在大型仓库（数万引用）下性能更优且支持原子更新。2.44 还引入了 git config 的 --type=color 等改进。
Git 2.45（2024 年 5 月）引入了 git config 的进一步改进与 git rebase 的优化，同时修复了若干安全问题（见后文 CVE-2024-32002 等）。2.46（2024 年 7 月）引入了 pseudo-merge bitmaps（伪合并位图，加速大型仓库的 git fetch 性能）、更强大的 credential helper 接口，以及新的 git config 子命令。2.47（2024 年 10 月）引入了增量多包索引（incremental multi-pack-index）、git refs 子命令（统一管理引用）、reftable 后端的持续完善，以及 git maintenance 的修复。2.47 的 git refs 子命令将原本分散在 git update-ref、git symbolic-ref、git for-each-ref 中的引用操作整合为统一接口，延续了 2.23 以来"命令职责清晰化"的演进方向。
11. 主要安全问题与处理
11.1 SHA-1 碰撞攻击（SHAttered，2017）
2017 年 2 月，Google 与 CWI Amsterdam 联合发布了 SHAttered 攻击，首次公开演示了 SHA-1 的实际碰撞——两个不同的 PDF 文件具有相同的 SHA-1 哈希。这一攻击直接威胁 Git 的完整性模型，因为 Git 使用 SHA-1 作为对象的内容寻址哈希。攻击者理论上可以构造两个具有相同哈希的不同 Git 对象（如两个不同的提交或树），在仓库中替换其中一个，而 Git 的完整性校验无法察觉。
Git 社区的应对分为两步。短期：Git 2.13（2017 年 5 月）引入了 sha1dc（SHA-1 with Collision Detection）哈希实现，该实现由 Marc Stevens 等人开发，能够在计算 SHA-1 的同时检测已知的碰撞攻击模式，一旦检测到攻击性输入会拒绝计算并报错。这使得 Git 在不改变哈希算法的前提下，获得了对 SHAttered 类攻击的免疫力。GitHub.com 同步启用了 SHA-1 碰撞检测，拒绝任何疑似碰撞的 Git 内容。长期：启动 SHA-256 迁移计划，详见 Documentation/technical/hash-function-transition.txt。Git 2.29（2020 年 10 月）引入了实验性的 SHA-256 仓库支持，允许新建仓库使用 SHA-256；但 SHA-1 与 SHA-256 仓库之间的互操作（如 push、fetch）需要"桥接"机制，相关工具在后续版本逐步完善，截至 2.47 仍在演进中。
11.2 CVE-2022-24765（仓库所有权漏洞）
2022 年 4 月披露的 CVE-2022-24765 影响 Git 2.35.2 之前的所有版本。该漏洞源于 Git 在执行 hooks、配置等操作时信任仓库目录的所有者——如果攻击者能够在一个共享系统（如多用户服务器、CI 构建机）上创建或修改一个仓库目录，当受害者在该目录中执行 git 命令时，攻击者可以通过 hooks 执行任意代码。这一漏洞在多用户系统与 CI/CD 环境中风险极高。
Git 2.36.2/2.35.4 等修复版本引入了 safe.directory 检查：Git 默认拒绝在所有权不属于当前用户的目录中执行操作，用户需通过 git config --global --add safe.directory /path/to/repo 显式信任特定目录。这一变更虽然给共享系统上的合法场景（如 root 拥有仓库、普通用户操作）带来配置负担，但显著提升了多用户环境的安全性。从用户视角看，升级后若遇到 “fatal: detected dubious ownership in repository” 错误，即需配置 safe.directory。
11.3 CVE-2024-32002（Windows 符号链接 RCE）
2024 年 5 月披露的 CVE-2024-32002 影响 Git 2.45.1 之前的版本（主要影响 Windows 与启用了符号链接的 macOS/Linux）。该漏洞允许恶意仓库在 git clone 时通过精心构造的符号链接与子模块组合，在克隆目标目录之外写入文件，甚至实现远程代码执行（RCE）。攻击原理是：恶意仓库包含一个子模块，其路径通过符号链接指向克隆目录之外的敏感位置（如 ~/.git/hooks），克隆时 Git 会将子模块内容写入该位置，从而在受害者下次进入相关目录时触发 hooks 执行。
Git 2.45.1（以及 2.44.1、2.43.4 等回溯修复版本）通过拒绝在符号链接路径下克隆子模块来修复此漏洞。同时披露的还有 CVE-2024-32004（Windows 上 git clone --local 的硬链接漏洞）、CVE-2024-32020（git apply --reject 的路径遍历）、CVE-2024-32021（Windows 上 git clone --local 的 RCE）、CVE-2024-32465（Windows 上过滤驱动漏洞）等多个相关漏洞。这一批漏洞的集中披露体现了 Git 在处理不受信任仓库时的攻击面之大，也促使社区加强了 clone/submodule 操作的路径校验。用户应避免克隆不受信任的仓库，并及时升级到最新版本。
11.4 其他重要安全修复
除上述重大漏洞外，Git 历史上还有若干值得注意的安全修复。CVE-2017-8386（git shell 远程命令执行，2.13 修复）影响了通过 SSH 提供 Git 服务的托管平台。CVE-2018-11235（子模块 RCE，2.17.1 修复）允许恶意 .gitmodules 在 git clone --recursive 时执行代码。CVE-2018-17456（.gitmodules 注入，2.19.1 修复）允许通过 .gitmodules 中的恶意路径执行任意命令。CVE-2023-29007（git config 中的符号链接漏洞，2.40.1 修复）允许本地攻击者通过符号链接覆盖文件。CVE-2025-46334（Git GUI 的 sh.exe/textconv 漏洞）影响 Git for Windows 的 GUI 组件。
从用户视角看，Git 的安全演进呈现两个趋势：第一，对"不受信任仓库"的防御日益严格——safe.directory、clone 时的路径校验、子模块的严格检查等，都体现了"克隆一个仓库不应导致代码执行"的原则；第二，哈希算法迁移的长期推进——SHA-1 碰撞检测是过渡方案，SHA-256 才是终态，但迁移涉及整个生态系统的协同，预计仍需数年完成。用户应保持 Git 版本更新（至少跟随最新的稳定小版本），并在共享系统上谨慎处理仓库所有权与 hooks 配置。
12. 总结与展望
12.1 演进脉络回顾
回顾 Git 二十年的功能发展，可以清晰地看到几条主线。第一，用户接口的持续精细化：从 1.5 的远程分支命名空间隔离，到 2.0 的 push.default=simple，再到 2.23 的 switch/restore 拆分、2.25 的 sparse-checkout 子命令化、2.27 的 maintenance 子命令化、2.47 的 refs 子命令化，Git 始终在努力让命令语义更清晰、默认行为更安全。第二，性能与可扩展性的持续突破：从早期的 commit-graph、multi-pack-index，到 partial clone、sparse-checkout、sparse index，再到 Scalar 集成、reftable 后端，Git 不断突破"单仓库规模上限"，从最初的内核规模（数万文件）演进到支持数百万文件的企业级 monorepo。第三，安全性的持续加固：从 SHA-1 碰撞检测到 SHA-256 迁移，从仓库所有权检查到 clone 路径校验，Git 在"不受信任仓库"这一攻击面上持续投入。
从用户视角看，这些演进带来的实际体验变化是：克隆大型仓库更快了（partial clone、Scalar）、切换分支更安全了（switch、push.default=simple）、恢复文件更直观了（restore）、维护仓库更省心了（maintenance 定时任务）、处理超大仓库更可行了（sparse index、fsmonitor）。同时，升级过程中也偶尔需要应对行为变更（如 2.0 的 push 默认值、2.36 的 safe.directory），但 Git 社区通常通过提前警告、保留旧命令、提供配置开关等方式将迁移成本降到最低。
12.2 未来展望
展望未来，Git 的演进方向已较为清晰。SHA-256 迁移仍是最重要的长期工作，预计未来几年将逐步完善 SHA-1 与 SHA-256 仓库的互操作工具，推动主流托管平台（GitHub、GitLab、Bitbucket）支持 SHA-256 仓库，最终实现新仓库默认使用 SHA-256。Reftable 后端有望在更多场景下成为默认，进一步提升大型仓库的引用操作性能。Sparse index 与 partial clone将继续优化，目标是让"按需加载"成为大型仓库的默认体验。协议层（protocol v2 及后续）将继续减少网络传输量，改善低带宽环境下的体验。
对于普通用户，理解 Git 的演进脉络有助于更好地规划工作流与版本升级策略。建议：保持 Git 版本相对较新（至少在最新稳定小版本的一两个版本之内），以获得安全修复与性能优化；学习并迁移到新命令（switch/restore/sparse-checkout/maintenance），享受更清晰的语义；在大型仓库中尝试 Scalar 与 partial clone，体验性能提升；关注 SHA-256 迁移进展，为未来的仓库哈希算法变更做好准备。Git 的二十年演进证明了一个活跃的开源社区能够持续推动一个基础工具的进化，而理解这一进化过程，本身就是成为高效 Git 用户的重要一环。
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
9
0- 0
已为社区贡献4条内容
所有评论(0)