如果我能自己搭建 GitHub
Source: Hacker News
我的十亿美元锻造想法
我和朋友有一个游戏，讨论如果我们有钱会怎么做。不是“付清房贷”那种有钱。是那种拥有一艘从未进去过的潜艇的人的富裕。是那种第三任妻子有自己的护肤品牌的人的富裕。科技巨头级的富裕——那种能让你在怀俄明买下一个复合体，并且有自信在国会听证会上穿同一件灰色 T 恤的金钱。
我长期以来的一个梦想就是打造一个全新的锻造平台。读了关于 Ghostty leaving GitHub 的好文章后，我决定把它写下来，但这其实是我写了好几年、也谈论过的想法。鉴于 GitHub 在其核心工作上已经变得糟糕，这似乎是一个有趣的机会，尝试写出我这位亿万富翁式的锻造平台会是什么样子。这个狂想将会少一些充斥老明星的“阴茎火箭”。
现代锻造平台存在哪些问题？
GitHub、GitLab 和 Gitea（我用得最多的三个）在本质上都采用了相同的设计。它们之间有差异，但可以看出 GitHub 为行业设定了模式，然后这些特性被移植到另外两个平台，成功程度各不相同。这些平台的共同问题在于，它们被设计成在 Git 本身不具备、而你需要的功能之上添加东西。
Git 在它被设计的用途上表现出色，但它的设计 并不是大多数人使用它的方式。Git 是内核开发的完美工具。它是一个去中心化、分布式的版本控制系统，依赖于通过电子邮件向维护者发送补丁的概念。你信任这些维护者去 维护 他们的代码段，合并有意义的改动而不合并其他东西。这是一个高度信任的环境，对特定贡献者的在线状态或使用的系统几乎没有限制。如果你有一台 2010 年的笔记本电脑，每周只连一次网，你仍然可以在这种工作流中对项目作出有意义的贡献。
然而，在大多数工作中，Git 实际上只是我从锻造平台的集中仓库拉取和推送的方式。所有重要的事情都发生在锻造平台内部，几乎没有在我的客户端上发生。
- Pull Requests（拉取请求）是我执行四眼原则的方式。
- GitHub Actions（GitHub 动作）是我在这些 Pull Requests 上运行测试和 lint（代码检查）的方式，以确保它们功能正常并符合组织要求。
- 与该锻造平台关联的用户身份是我验证他们身份的依据。
- 我通过 Issues（议题）跟踪代码问题，并通过 Releases（发布）为用户提供下载。
在这个工作流中并没有太多 Git 的使用；它主要是 在 Git 之上 添加的层。
下面是我在现代锻造平台中看到的主要问题，以及我希望解决的方向。
| # | 问题 | 期望的改进 |
|---|---|---|
| 1 | 事情发生的顺序错误 —— 反馈在 提交 之后，而不是之前。 | 强制的 pre‑commit（预提交）钩子，在锻造平台上远程运行作业，并在 推送之前 提供反馈。 |
| 2 | PR 审批过于二元 —— PR 要么被批准，要么不被批准。 | 中间状态（例如 “弱批准”、 “需要后续跟进”），类似 Gerrit 的模型，允许维护者标记 PR 以便稍后审查。 |
| 3 | PR 过于僵硬 —— 每一次改动都必须通过四眼检查，即使 LLM（大语言模型）可以安全评估风险。 | 可定制的审批策略：如果作者是维护者且 LLM 判定改动风险低，则允许自动合并。 |
| 4 | 堆叠 PR 本就更好 —— 它们更易于审查和理解。 | 将堆叠 PR 设为一等公民，而不是外部 VCS 的附加工具。 |
| 5 | 锻造平台不应做所有事 —— 议题跟踪可以，但看板、维基等常常沦为低质量的冗余。 | 保持核心精简；避免 “功能膨胀”，让用户不必维护不想要的组件。 |
| 6 | 托管的标准单元太大 – GitHub Enterprise 和 GitLab 需要重量级基础设施。 | 提供小型、可组合的托管单元，可以链接在一起形成组织（例如，“这 12 台 Raspberry Pi 是我的组织”）。 | | 7 | 本地克隆应当代表 整个 仓库，而不仅仅是代码。 | 允许用户在同一个本地 VCS 视图中批准 PR 并浏览 issue，就像他们检入代码一样。 | | 8 | 不要强制持续的存储费用 – 我需要一直在线，但不应为每个克隆支付完整历史的费用。 | 默认克隆浅层历史；在需要时通过后台工作者懒惰地获取更深的历史。 | | 9 | 操作需要签名、SHA‑哈希，并且能够离线使用 – 可复现性和安全性至关重要。 | 提供一种机制，使签名的确定性操作可以在没有与 forge 实时连接的情况下运行。 |
……列表仍在继续。
这些是我想在下一代 forge 中解决的痛点，它既尊重 Git 的强大功能，又符合现代开发工作流的实际情况。
# Action Tarballs and a Self‑Hosted Forge
I should be able to get tarballs of all my actions, stick them in the repo, and tell my system “don’t go anywhere for checkout action, that’s right here.”
If I say **latest**, have that work like Dependabot does now—opening a PR to put the latest tarballs in my repo. Actions are critical, and they should be runnable on my local machine through the same VCS if I want to.
### Well Y Does Some Of That
Absolutely. There are a lot of tools that do parts of this. I want someone to take them, put them all together, and fit them up. I want **JJ** as the VCS, I want this as the forge, and I want the expectation that I, as a user, could live happily with a Raspberry Pi as a forge for a long time. I want those forges designed around modern concepts like object storage, shallow clones, and getting constantly hammered by LLM bots.
Now, in a universe where GitHub was doing a good job, I wouldn’t even bother writing this up. GitHub is the default, and talking to people about overcoming the default is usually a waste of time. Heinz is the default ketchup; when I order a Coke I don’t want a Pepsi. If I’m going to use a forge up until 2026, there would have to be an amazing reason for me not to choose the one that everyone uses. Up until recently, other forges have been like sweet‑potato french fries—that is, never the thing you actually want.
But we live in a world where the monolithic forge is breaking down and nobody has built the replacement. The people with the money are busy with the rockets. The people with the taste are busy with their day jobs. And the rest of us are opening PRs titled “asdfasdf” at midnight, waiting for a robot to check them, wondering when the tool we spend our whole working lives inside stopped being built for us.
If I ever get the submarine money, I’ll let you know.