Ghostty 离开 GitHub 后，开发者 Mat Duggan 在 4 月 30 日写了一篇博客：《If I Could Make My Own GitHub》。题目很直接：如果让我重新做一个 GitHub，我会怎么做。

这不是 GitHub 的新产品消息，也不是某个替代平台的融资计划。它更像一份开发者写给开发者的工具诊断。触发点是 Ghostty，但文章真正盯住的是另一件事：Git 还没坏，变重的是围绕 Git 堆出来的 forge。

我更在意的也在这里。过去十几年，我们把代码评审、CI、权限、Issue、Release、包管理和存储都塞进一个中心化平台。方便是真的，包袱也是真的。

Git 没坏，变重的是 forge

Git 最初适配的是另一种协作方式：邮件补丁、维护者合并、模块负责人把关。Linux 内核式的工作流需要容忍离线、低带宽和高度分散的贡献者。

今天多数企业团队不是这么用 Git。Git 更像连接中心化平台的 push/pull 工具。真正的研发流程发生在 GitHub、GitLab、Gitea 这类 forge 里。

PR 是评审入口。Actions 或类似系统跑测试。账号和组织管理权限。Issues 管需求和缺陷。Releases 负责交付包。Git 还在，但舞台已经换了。

环节Git 早期协作思路现代 forge 的常见做法Duggan 不满的点
代码评审邮件补丁、维护者合并PR 成为默认关口反馈太晚，常在提交后才暴露问题
CI本地脚本或外部系统与平台深度绑定依赖应可签名、可固定、可缓存，最好能离线复现
权限信任维护者网络账号、组织、分支保护规则审批太二元，缺少弱批准、延期处理等中间状态
Issue / Release不属于 Git 核心由 forge 一并承包好用，但会把项目管理也绑进平台
存储本地可拿完整历史大仓库克隆成本上升VCS 与 forge 应更好支持浅克隆和按需取历史

GitHub 成为事实标准，不是偶然。它把这些环节做成了一站式体验。团队少配很多东西，新人也容易进入流程。

但默认选项会反过来塑造工作方式。一个团队如果所有审批、CI、发布、权限和历史存储都挂在同一个平台上，迁移成本就不只是一份代码仓库。它变成流程迁移、权限迁移和习惯迁移。

所以这件事不该被简化成“GitHub 行不行”。更准确的问题是：单体 forge 把太多开发动作合在一起后，是否还适合今天的协作密度。

新 forge 想改的不是 Logo，而是流程顺序

Duggan 的设想里，最明确的偏好是 JJ。也就是 Jujutsu，一个更强调变更组织和历史编辑体验的版本控制系统。

他希望堆叠 PR 成为一等公民。不是把一大坨修改攒成一个 PR，再让维护者从头读到尾，而是让一组相关变更天然分层。每层都能评审、修改、重排。

他还想把反馈提前。理想状态下，开发者在正式 push 之前，就能触发远端任务，提前知道测试、lint 或依赖检查会不会过。这样 PR 不再是问题第一次暴露的地方。

审批也不该只有“通过”和“不通过”。Gerrit 早就证明，patch set 和细粒度评审有价值。只是 Gerrit 的学习曲线和产品体验，对很多团队并不友好。

Duggan 想要的是把这些能力重新组合：保留细粒度评审，但降低使用门槛；支持堆叠变更，但别让开发者每天和工具搏斗。

这里有一个很重要的取舍：少做平台大而全。

Issue tracking 可以有。Release 可以有。Kanban、Wiki、复杂项目管理未必都要塞进去。平台一旦什么都做，就会越长越厚。到最后，维护平台本身也成了项目负担。

更有意思的是部署尺度。Duggan 希望一个组织可以由多个小型 forge 单元组成，甚至能在树莓派级别的设备上长期运行。

这个想法有吸引力，但不能浪漫化。小型部署会立刻遇到安全通信、备份、权限同步、审计和升级问题。企业里的麻烦从来不会因为机器变小就消失。

LLM 也出现在他的设想里。比如维护者的小改动，如果模型判断低风险，可以减少审批阻力。

我不太买账把它当成今天的自动合并标准。模型可以辅助分流，但安全责任、误判成本和审计链条仍然要由团队承担。现在更稳妥的用法，是让它帮维护者排序、解释和检查，而不是直接替人拍板。

真正受影响的是维护者和平台工程团队

这类讨论最容易跑偏成“要不要离开 GitHub”。但对大多数团队来说，立刻迁移并不是最现实的动作。

更现实的动作，是把流程拆开看。

开源维护者最该看三件事：PR 是否经常排队、CI 是否过度依赖远端 Action、评审规则是否让小改动也要等完整审批。如果这些问题高频出现，可以先引入堆叠 PR 工具、合并队列、可复现 CI，而不是先搬家。

DevOps 和平台工程团队要看另一组问题：大仓库是否拖慢克隆，CI 依赖能不能固定和缓存，权限审批是否足够细，离线或内网环境能不能复现构建。这里决定的是工具链设计，不只是代码托管选型。

技术负责人则要压住冲动。不要把一篇个人博客当成迁移路线图。更合理的做法，是延后“换平台”的大决定，先做一次流程盘点：哪些能力只是 GitHub/GitLab 的默认便利，哪些能力已经变成锁定。

可以用一个简单表格判断优先级。

角色现在最该做什么不该急着做什么
开源维护者统计 PR 等待、CI 排队、重复审批的消耗因为一次迁移案例就仓促搬仓库
DevOps / 平台工程检查 CI 依赖签名、缓存、本地复现和浅克隆支持把所有问题都归因于 GitHub 或 GitLab
技术负责人盘点平台锁定点，评估堆叠 PR 和权限模型是否值得试点把个人设想当成成熟商业方案采购

接下来最该观察的也不是“谁推翻 GitHub”。这个问题太大，也没有足够证据。

更具体的变量有三个。

一是 JJ、堆叠变更和浅克隆能不能进入日常开发，而不是停在少数爱好者手里。

二是 CI 依赖管理能不能做到可签名、可缓存、可本地复现。没有这一步，提前反馈和离线运行都很难落地。

三是小型 forge 能不能解决备份、权限、审计和升级。如果这些基础问题解决不了，树莓派级别部署就只能是漂亮的实验。

Ghostty 离开 GitHub不是结论，只是把老问题照亮了一下。代码托管平台这些年一直在加功能，但开发者真正需要的，可能是把协作、CI、存储和 VCS 重新拧紧，而不是继续往同一栋楼上加层。