为维护者打造的 GitHubA GitHub for maintainers

马特·达根（Mat Duggan）列出了他对 GitHub 替代品的期望，这份清单相当合理——尤其是当你需要亲自操作键盘的时候。它包括堆叠式 PR、推送前反馈、离线审查、惰性历史记录以及分阶段审批状态。通读下来，我注意到几乎所有项目都涉及客户端问题，而这些问题用户早已自行解决。Jujutsu 在实现堆叠变更方面比任何网页界面都要出色。代码审查正逐渐融入编辑器中。推送前的反馈则希望在本地运行，因为文件就在那里。

我对“代码托管平台”（forge）的需求，是那些无法迁移到客户端的功能——因为它们涉及多方协作。谁依赖着你，你又依赖着谁？三年前你 fork 的那个项目后来怎么样了？当原始项目沉寂后，活跃开发又转移到了哪里？这些情况几乎不会发生在单个仓库内部。它们存在于仓库之间的关系之中，而这正是 GitHub 多年来几乎未曾触及的部分，也是所有潜在的替代品所忽视的领域。

因此，我所理解的马特那份清单，主要关注的是跨项目的协调。GitHub 实际上只建模了一种仓库间的关系：fork。因为在 2008 年，使用他人代码的方式就是 fork 并发送 pull request。但到了 2026 年，人们只需在清单文件中添加一行即可引入外部代码，而当前的 forge 对此并无对应对象。它仅将依赖项视为生成 Dependabot PR 的工具。我希望它能像对待 fork 那样，给予依赖项同等重视。

下游测试

当我准备发布一个库时，我希望平台能先运行我的测试套件，然后检出若干依赖该库的项目，并用我的改动执行它们的测试。Rust 称此为“crater run”，并将其保留给编译器专用。这应该成为每个发布 PR 上的一个按钮。目前我只能通过上千条愤怒的工单才知道自己破坏了上千个下游项目——而这些工单往往是在标签推送之后才出现。只有平台拥有完整的依赖图谱和计算资源，才能提前告知我这一结果。事实上，这些工单反而是较好的结局，更糟的情况是它们会锁定旧版本，导致项目从此不再升级。

依赖者的信息流

如果我计划在下个大版本中移除某个已弃用的函数，今天我只能将其写入无人阅读的变更日志，或者发出运行时弃用警告——正如塞思·拉森（Seth Larson）指出的 Python 情况那样，这种警告通常也传达到不了人类开发者。我希望这些信息能自动发布到一个信息流中，所有在其 lockfile 中包含我包的项目默认都会订阅该流。同一频道还会推送“本项目正在寻找维护者”、“我们将迁移仓库地址”以及“发现 CVE，这是修复后的版本”等内容。GitHub 在 2008 年将“社交编程”（social coding）放在首页，随后围绕“关注人”构建了整个社交层。真正有用的做法应是关注实际运行的代码——通过 lockfile 订阅——这才是更有价值的版本。

Fork 网络

当一个项目沉寂下来时，社区的反应通常是大家各自独立地打补丁或分叉它，最终其中一个分叉会逐渐流行起来，用户通过口口相传和置顶的问题慢慢发现它。代码托管平台可以看到这一切：它知道上游项目已经18个月没有合并提交，而三个分叉项目都有活跃的发布标签和新增的星标。与其让用户自己去挖掘这些历史，不如在原始仓库页面上展示这些信息，并让分叉项目的维护者表明他们自认为是该项目的延续。GitHub的网络图谱自2010年以来一直显示着这种难以理解的混乱局面，显然存在一种更清晰的解决方案。

借鉴自 npmx 列表

一旦代码托管平台认真对待依赖关系，它就与包注册中心前端的功能开始重叠。几周前我整理了 npmx 功能清单，作为用户自行设计时的参考范例。其中许多功能既适合放在仓库页面，也适合放在包页面：

更安全的CI默认配置

关于这个问题我已经写过两次，一次是关于Actions作为没有lockfile的包管理器，另一次是关于所有供应链事件都追溯到工作流文件的情况，这里就不再重复了。简而言之，现在大多数开源构件都是在代码托管平台的CI上构建和发布的，而这些默认配置最初是为私有企业仓库设计的。任何新建立的代码托管平台都可以选择新的默认配置：固定版本的actions、隔离的缓存，完全禁止陌生人触发的workflow。

CI中的包缓存

每个代码托管平台上的每次CI运行都会从相同的公共注册中心下载相同的包集合，而这些注册中心大多由非营利组织运营，带宽费用来自捐赠。在npm、PyPI、RubyGems、crates.io等前面设置一个代码托管平台运行的缓存代理，并将其默认集成到CI运行器中，将大大减轻这些基础设施的压力，并在注册中心出现问题时保持所有人的构建正常运行。git-pkgs/proxy 是该想法的一个实现方案。代码托管平台已经有了lockfile，因此它甚至知道要预加载哪些内容。

重命名"issues"

这与依赖图无关，但既然我在列清单：功能请求不是问题，提问不是问题，将所有到达维护者收件箱的内容统称为"issue"，会在任何人打字之前就设定了对话的温度。我认为这比人们意识到的更能助长维护热门项目的普遍敌意。"工单"听起来平淡中立，而这正是关键所在。

超出范围

我没有提到AI、联邦或企业权限。我现在不打算讨论AI。我之前写过关于联邦的内容，难点在于命名，我不会在这里假装解决了这个问题。而且我对企业功能完全不感兴趣。如果你的关注点不在这里，那很可能就是上述那些之一。

维护者需要帮助确定下游依赖者，并在问题出现前与他们沟通，同时跨项目协作而非孤立工作。随着依赖关系日益复杂，这项工作每年都在变得更加困难，但几乎没有新的工具来提供支持。企业内部没有类似机制，因为内部代码库通常不会有上千个未知的下游依赖，因此唯一能从中受益的是那些拥有大量公开依赖图且没有预算的开源维护者。这或许也是 GitHub 尚未开发此类功能的原因。任何构建新代码托管平台的人都可以从这里开始。