导读：越来越多的AI Agent涌入正将 GitHub 推向崩溃的边缘。

上个月，HashiCorp联合创始人米切尔·桥本（Mitchell Hashimoto）公开宣布，他将把广受欢迎的开源终端模拟器项目Ghostty从GitHub迁移了出去。

众所周知，GitHub运行着全球最大的基于Git分布式版本控制系统的服务平台，该系统由Linus Torvalds创建。

曾经是GitHub“超级热情用户”的桥本， 后来对服务中断和日益缓慢的拉取请求感到失望。“如果每天都要浪费你几个小时，这里就不再适合认真工作了，”他如此写道。 

桥本也为 Git 平台做公正的辩护：“问题不在于 Git，而在于我们围绕它所依赖的基础设施：issues、PRs、Actions 等。”

2025年，GitHub上基于Bash shell脚本（一种广泛使用的AI代理运行方式）生成的AI项目数量同比增长了206% 。而AI代码的增多也意味着bug的增多。

GitClear的研究发现，AI生成的代码平均每个拉取请求会产生10.83个问题，而传统的人工代码平均每个拉取请求只会产生6.45个问题。

我们这个新型自主型员工队伍提出了关于整个软件开发生命周期 (SDLC) 应该如何演变以及 Git 是否应该随之发展的重大问题。 

“代理正在推动我们走向持续流动，” DevOps 平台提供商Autoptic的联合创始人佩科·卡拉亚内夫（Peco Karayanev）警告人们说。Autoptic 将基于 Git 的部署与基于代理的修复的可观测性工具连接起来。

Autoptic 的所有用户都使用某种形式的 Git，无论是自制的还是来自 GitLab 等服务提供商的。 

鉴于代码库中变更的数量和幅度，“我们需要 git 开始以更加连续的方式运行，”佩科·卡拉亚内夫（Karayanev）在一封电子邮件采访中写道。

Git 管家

Git 一直以来都饱受批评，尤其是那些每天都使用该工具的人。 

或许没有哪款版本管理软件像 Git 这样被广泛采用，却又如此晦涩难懂。Torvalds 和其他几位 Linux 内核开发者在 2005 年创建了Git，起因是他们曾试图将 Linux 代码硬塞进商业工具 BitKeeper 中，但中间屡屡碰壁。Linux 作为一个规模庞大的全球性项目，需要一个分布式版本控制系统来支持数千个并行分支的非线性开发。 

与其他分布式系统一样，Git 也较难理解。

GitHub 的联合创始人之一斯科特·查孔（Scott Chacon）与人合著了一本关于使用 Git 的书（2009 年出版的《Pro Git》），但他仍然偶尔会被版本控制系统搞得一头雾水。

查孔称，Git仍然存在一些“明显的不足” 。他说：“从可用性的角度来看，它有很多方面做得不够好。” 

他与其他合作者共同创立了GitButler，旨在“重新思考 Git 的本质”，使其更适合现代工作流程。（上个月，GitButler喜获 1700 万美元的风险投资。） 

我们可以将 GitButler 看作是一个功能强大的 Git 客户端。它允许开发者使用一种称为虚拟分支的技术，同时在两个不同的分支上工作。它能够将开发者正在处理的代码与上游代码进行同步。开发者可以重新排列提交顺序，或者编辑先前提交的注释。它提供更丰富的正在处理的文件元数据，并能显示哪些提交是该分支独有的。

最重要的是，它消除了许多开发者所说的“变基地狱”，即必须一次检查一个合并到更新后的代码库中的代码，而 GitButler 通过保持用户代码与上游代码同步来解决这个问题。

查孔还说，GitButler 提供的许多操作都可以通过 Git 命令本身完成——尽管 Git 的命令语言及其规则可能非常晦涩难懂，“你很可能会在某个时候犯错”。

AI代理上的 Git

Chacon 认为 GitHub 目前的可靠性问题源于当前大量AI代理工作的涌现。 

他说，这非常“讽刺”，因为GitHub的设计初衷就是为了扩展Git。“但代理数量的激增正将这项服务推向崩溃的边缘。”

查孔认为，问题不在于Git本身，而在于所有人都在使用同一项服务。根据GitHub最新发布的年度报告《Octoverse》，去年GitHub拥有约1.8亿用户，在6.3亿个代码仓库中工作——仅2025年就将新增1.21亿个代码仓库。 

“从长远来看，情况不应该如此，”他认为。查孔建议，或许 Git 应该在本地运行，全球镜像，并由客户端进行管理，例如 GitButler。或许可以针对特定行业垂直领域定制基于 Git 的版本控制系统。 

他说：“我们需要思考如何更好地‘分布式部署这些系统’。Git 的设计初衷就是分布式部署，但我们并没有真正实现这一点。”

GitButler 专门为代理创建了一个命令行界面。它的设计目的是为MCP服务器提供一个集成的代码库映射，否则服务器需要拼接多个 Git 命令才能实现此功能。虚拟文件概念允许代理在开发人员或其他代理也在处理同一代码段时进行操作。

这些变化表明，我们需要重新思考 Git 工作流程的运行方式。 

“我认为所有这些系统都应该从根本上改变，因为我们的工作流程都发生了变化，对吧？我们需要一些不同的、类似基本方法的机制来处理这些问题，”查孔说道。 

来自游戏开发的一个技巧

Diversion是一家希望其平台完全取代 Git 的公司，该公司构建了一个同名的分布式版本控制系统，最初是为大规模游戏研发而设计的。

Diversion 首席执行官萨沙·梅德韦多夫斯基（Sasha Medvedovsky）在接受采访时表示道：“Git 的架构实际上是一个阻碍其扩展的问题。从根本上讲，这是一个无法解决的架构问题，并且是最终用户和托管服务的瓶颈。”

从某种意义上说，Git 是一个分布式系统，因为每个用户或托管服务都需要一个专用数据库（很如同区块链）。“它并非传统意义上的分布式系统，而是复制式的，”他在 LinkedIn 上发表的文章中如此写道。 

操作在单线程上运行，因此无法进行并发操作。梅德韦多夫斯基指出，结果就是，代码库越大，提交操作就越慢——这对快节奏的智能软件开发来说将是致命的。 

当然，每位CEO都会准备好应对竞争对手弱点的说辞，梅德韦多夫斯基正在撰写一篇博文，其中包含关于Git和GitHub性能的硬数据。与此同时，还有越来越多的举措致力于帮助Git系统应对未来充满挑战。

最值得一提的，或许是Jujutsu(jj) ，这是一个与 Git 兼容的分布式版本控制系统，由谷歌高级软件工程师马丁·冯·茨威格贝格（Martin von Zweigbergk）维护。

与 GitButler 类似，Jujutsu 旨在消除 Git 带来的诸多不便。它包含撤销按钮，并且即使存在冲突也能继续提交。 

如今很多用 C 语言编写的代码都在重写为 Rust，Git 的长期贡献者塞巴斯蒂安·蒂尔（Sebastian Thiel）发起了一个名为Gitoxide 的项目， 旨在用 Rust 重建 Git。它潜在的优势包括通过多核处理显著提升性能，以及Rust 本身提供的急需的内存安全特性。

Git 3 能解决问题吗？

Git 的主要维护者是滨野纯（Junio Hamano），他在 2005 年从 Torvalds 手中接过 Git 的领导权，一直致力于保持 Git 的最新状态。

在今年二月在 FOSDEM 大会上，Git 核心贡献者兼 GitLab 工程经理帕特里克·斯坦哈特（Patrick Steinhardt）讨论了Git 的下一个版本（称为版本 3）即将发生的一些变化，或将于今年逐步推出。 

其中一项主要改进在于 Git 管理提交引用的方式，也就是指向每次更改的 ID。令很多人惊讶的是，这项操作竟然是软件的一大瓶颈。“目前的设计效率低下，”斯坦哈特对人们说道。

每次开发者提交代码更改时，都会将其记录在“packed-refs”文件中，这样就无需为每次提交都创建单独的引用文件，从而节省了时间。 

然而，伴随着项目规模的扩大，Git 修改或删除 packed-refs 中的引用所需的时间也更长（斯坦哈特表示，一个 GitLab 仓库的 packed-refs 文件包含超过 2000 万个引用）。 

当多个用户同时读取和写入该文件时，问题尤其严重。而且，想要获得所有引用的一致视图更是难上加难。 

新近实现的 Reftable 功能（将在 Git 3.0 中成为默认设置）以可索引的二进制格式存储引用。Git 团队在此处借鉴了 Eclipse 基金会的JGit Java 实现中的这一概念。 

另外，Reftable 支持块级更新，无需为单个条目重写 2 GB 大小的文件。且它的读取速度更快，这将为 Git 支持更大、更复杂的代码库铺平道路，这非常适合忙碌的独立工作者。

近20年来，Git 一直是全球极客们首选的版本控制系统。

但是，根据现在的情况，即便有了这些新功能和各种第三方增强功能，它还能对新一代更具自主性的程序员保持吸引力吗？ 

作者：场长