Git之后是什么

# Git之后是什么 来源：https://ersc.io/blog/what-comes-after-git 东河源代码控制已运营一年有余，但我们尚未公开过多谈论正在进行的工作。我们目前还不会宣布任何具体事项，但很快会进行分享，因此希望先与各位探讨一些关于版本控制及行业发展方向的思考。 ## 软件开发已今非昔比 软件构建本质上是一项协同任务。项目往往始于微末，最终发展成庞大而复杂的系统。但无论是`cargo new`生成的初始项目，还是包含数十亿行代码的巨型单体仓库，其核心都是源代码。如何安全可靠地存储这些代码、管理其随时间推移的变化、并确保开发者能够顺畅访问，这些已成为任何技术组织最关键的功能之一。 过去，代码可能存储在共享服务器上。学术界与产业界先后开发出如今被称为源代码管理（SCM）和版本控制系统（VCS）的工具。即使在VCS领域内，多年来也涌现出诸多工具：CVS、SVN和Git主导了开源生态，但同时也存在其他系统（https://en.wikipedia.org/wiki/List_of_version-control-software）：Perforce、ClearCase、Fossil、Mercurial、SCSS、Monotone、BitKeeper等等。这些工具逐渐成为存储代码与团队协作开发的标准方案。 智能体开发模式的兴起改变了软件开发的诸多方面，但对版本控制系统造成了特殊压力。团队产生代码的速度与数量空前增长，导致仓库规模膨胀、活跃分支增多，并在合并新代码时产生严重的资源竞争。智能体尤其适合单体仓库，因为它们能更便捷地获取更全面的上下文信息，这反而加剧了上述问题。同时，智能体正将开发环境迁移至云端的隔离环境，这意味着需要极快的克隆速度。这些问题过去通常是大型企业才面临的挑战，但智能体正将其带入所有开发者的日常。 我们认为，随着组织持续扩展技术抱负，他们将需要下一代VCS工具。但他们对该领域新工具的采用保持谨慎是完全合理的。如前所述，源代码是组织最宝贵的资产之一，变革既带来收益也伴随风险。我们深刻理解这些关切，因此正致力于搭建一座连接现在与未来的桥梁。 ## 存储是基石 市面上已存在众多Git服务器，我们的独特之处何在？ 从高层架构看，大多数Git托管平台的工作流程类似于： 服务器 ← Git协议 ← Git客户端 ← Git服务层 ← Git仓库存储 这是大多数Git托管平台的构建方式：您的`git`客户端通过Git协议连接服务端，服务端将仓库存储在磁盘上，并通过服务层实现对接。 当然这仅是高度简化的描述——实际会涉及多台服务器、复杂的前置服务层、存储复制机制等多重架构。我们聚焦整体设计框架，但切勿因图示简单而误解系统的复杂性。其内部运作机制极为精妙，但此刻我们暂不深入细节。 基于此理念，我们的架构设计如下： 服务器 ← Git协议 ← Git客户端 ← Git桥接器 ← 非Git存储引擎 这是东河源代码控制的构建方式：看起来颇为相似！该图同样进行了简化（例如未包含GraphQL API接口），但关键区别在于：尽管您仍使用常规`git`客户端通过Git协议连接我们的存储系统，但我们的服务器并不存储`git`仓库，而是采用定制化存储引擎。 ## Git并非面向未来 坦白而言，我们认为Git并非源代码控制的未来。Git多年来为开发者提供了可靠服务，但其设计基于2005年的技术约束，而非2025年甚至2035年的技术环境。例如，Git最初为Linux内核这一开源项目而生。开源对行业至关重要，但这意味着它缺乏非公开代码组织所需的关键功能。虽然Linux内核并非小型仓库（7.2版本约含4300万行代码），但业界主要企业的单体仓库早在数年前就已达到数十亿行代码的量级。在如此规模下，技术选择至关重要。 然而，转向其他版本控制系统也面临挑战。Git已深度融入现有工具链——现在流行的是GitOps而非SvnOps！众多系统都兼容Git协议，这使得替代方案难以推行。Git诞生之初，Mercurial和Bazaar等项目也同期启动，但网络效应促使Git最终成为行业事实标准。 那么该如何应对？我们的策略是：保持Git协议兼容性，同时革新底层存储架构。虽然这无法解决我们预见的所有未来问题，但能带来显著改善。我们的系统可实现水平扩展，而基于Git仓库的系统则难以做到。此外，由于这不是全局统一平台，其他组织的使用不会影响您的运行环境（各部署相互独立），这为基础设施带来了可靠性与可控性——这两者在基础设施建设中至关重要。 ## 面向采纳的工程设计 那么未来的可能性呢？当您需要突破Git协议的限制，或需要Git未提供的特性时怎么办？这种保持协议兼容的策略具有独特优势：您可以同时支持多种协议。 这便引出了Jujutsu（https://www.jj-vcs.dev/latest/）项目。东河源代码控制团队是`jj`的忠实拥趸，部分原因在于我们欣赏其渐进式采用的技术典范。虽然`jj`是独立的版本控制系统，但它能够对接多种后端。多数开发者通过Git后端使用`jj`直接操作本地Git仓库，但谷歌也为他们的Piper版本控制系统开发了专用后端。这使得个别开发者即使同事仍在使用常规Git客户端，也能在工作中选择`jj`——对服务器而言，它只是Git协议的又一个用户。我们将借鉴这种策略，但应用于服务端： 服务器 ← Git协议 ← Git客户端 ← Git桥接器 ← 非Git存储引擎 服务器 ← Git协议 ← `jj`客户端 ← Git桥接器 ← 非Git存储引擎 服务器 ← 原生协议(未来) ← `jj`客户端 ← 原生协议桥接器(未来) ← 非存储引擎 这为版本控制的未来演进提供了平滑路径：您可以继续使用熟悉的`git`工具，享受可靠且可扩展的源代码管理服务。开发者可以按自身节奏选择采用`jj`，当组织准备迈向新阶段时，`jj`能够通过不同协议与同一底层引擎交互。 需要特别说明的是：这属于未来规划，目前尚未实现。上游`jj`目前不存在"原生协议"，我们也不声称正在构建此类系统。如果这种方案对上游社区具有价值并希望得到支持，我们将与社区协作开发。该协议将提供完整文档，任何支持该协议的客户端修改都将开源。我们不会假设上游必然采用此方案，因为Git协议已能满足当前大多数用户需求。无论`jj`生态系统最终形态如何，我们都将致力于成为其良性参与者。 ## 系列构件的起点 存储解决方案仅是团队代码协作需求的一部分。代码评审、CI/CD、问题追踪等需求无穷无尽。虽然传统代码托管平台提供一体化解决方案，但我们认为软件行业正进入更具定制化的新时代。因此，我们的产品矩阵更像模块化构件而非单一平台。存储是基石，因此将率先推出。但请相信，我们的存储方案将与您的现有软件栈协同工作，而非相互排斥。虽然我们将在VCS领域提供多款产品，但您可以选择自带其他技术栈组件。同样，您也可以混合采用我方产品与自有工具。 尽管上述内容尚未正式推出，但我们即将启动开放计划。在此之前，我们将于下周在JJ Con (https://git-merge.com/)与各位相见！ ← 所有文章 (https://ersc.io/blog)