当 GitHub、镜像站和 AI 编程工具同时掉链子：开发者该重新思考自己的基础设施了

最近几天，开发者社区连续遇到几类很容易让人产生共鸣的问题：

GitHub 出现大规模故障，平时用来缓解依赖获取问题的镜像服务也可能出现同步或访问异常，而越来越多依赖云端的 AI 编程工具也开始进入开发者的日常工作流。

单独看，每一次故障都可以解释成一个普通的技术事故。

但如果把它们放在一起看，会发现一个更值得警惕的问题：

我们正在把越来越多的软件开发工作交给少数几个平台。

而且这种依赖正在变得比以前更深。

Git 在本地，但软件开发已经不在本地

很多开发者会说：

“Git 是分布式的，GitHub 挂了，我本地还有代码。”

这句话技术上没有错，但现实中的软件开发早已经不只是 git commit 和 git push。

一个现代项目通常还依赖：

• GitHub/GitLab 上的 Issue
• Pull Request
• Code Review
• CI/CD
• Release
• Package Registry
• Container Registry
• Webhook
• Secrets
• Actions
• Bot
• OAuth 登录
• 文档和 Wiki
• AI Coding Agent
• 自动化部署

所以真正的问题不是：

“我的代码有没有备份？”

而是：

“如果这个平台突然消失几个小时，我还能不能继续工作？”

这两者是完全不同的问题。

AI 编程让这个问题更加明显

过去，GitHub 更像是一个代码协作平台。

今天，它正在逐渐成为 AI 软件开发基础设施的一部分。

开发者越来越习惯：

AI 读取 Repository。

AI 分析 Issue。

AI 创建 Branch。

AI 修改代码。

AI 提交 Pull Request。

AI 运行测试。

AI 根据 CI 结果继续修改。

最后自动 Merge 和 Deploy。

这条流水线非常高效。

但它也产生了一个新的风险：

当越来越多 Coding Agent 同时依赖同一个代码平台时，一个平台的故障可能影响的不再只是“看不了代码”，而是整个软件生产流程。

最近 GitHub 的故障讨论中，就出现了请求重试进一步放大流量、最终形成级联影响的情况。

这其实是现代分布式系统里非常经典的问题：

一个服务越重要，越多人依赖它；越多人依赖它，故障时的放大效应就越明显。

AI 时代只是让这种效应更加明显。

镜像站也不是万能药

很多国内开发者已经形成了一个很好的习惯：

国外的软件源访问不稳定，就使用国内镜像。

这是非常正确的基础设施意识。

但镜像和代码托管解决的是两个完全不同的问题。

例如，一个镜像站可以帮助你获得：

• Linux 软件包
• Python/PyPI 相关资源
• Rust 相关资源
• Node.js 相关资源
• GitHub Release
• 各类开源项目源码

但它并不能替代：

• Issue
• Pull Request
• Code Review
• CI
• Repository 权限
• 项目社区
• Release 管理
• 开发者身份

所以：

镜像是冗余的一部分，但不是完整的代码基础设施冗余。

那么 GitHub 的替代品有哪些？

其实不少。

1. GitLab

如果你需要完整的企业级 DevOps 平台，GitLab 依然是非常强的选择。

它不仅仅是 Git Hosting，还包括 CI/CD、Registry、安全扫描以及大量团队协作能力。

问题也很明显：

它很强，但也很重。

如果只是想给自己的开源项目找一个 GitHub 替代品，部署一套完整 GitLab 往往属于杀鸡用牛刀。

2. Gitea

Gitea 是非常成熟的轻量级 Git Forge。

它最大的优势就是简单。

如果你有一台 VPS，希望自己掌握代码托管服务，Gitea 是很自然的选择。

3. Forgejo

如果现在重新选择一个自建 Git Forge，我更倾向于关注 Forgejo。

Forgejo 是自由软件，可以自己部署，而 Codeberg 本身就是建立在 Forgejo 之上的平台。

这意味着一个非常重要的事情：

Codeberg 不是一个必须永久依赖的黑盒 SaaS。

你可以使用 Codeberg。

也可以运行自己的 Forgejo。

甚至可以在未来从一个 Forgejo 实例迁移到另一个 Forgejo 实例。

这才是真正意义上的可迁移性。

4. SourceHut

SourceHut 是另一个非常有意思的选择。

它的设计哲学和 GitHub 很不一样，更强调 Git、邮件列表和 Unix 风格的开发流程。

如果你喜欢极简工具链，它值得研究。

但如果你已经习惯 GitHub 的 Pull Request、Web UI 和现代协作方式，那么它的学习成本会明显高一些。

表格对比

平台	更适合谁	核心优势	主要问题
Codeberg	个人、FOSS、独立开发者	非营利、Forgejo、社区驱动	生态和 GitHub 仍有明显差距
Forgejo 自建	团队、公司、极客	真正掌握基础设施	自己负责运维
GitLab	中大型团队	CI/CD、DevSecOps、企业功能完整	重，运维成本高
Gitea	自建、小团队	轻量、成熟	与 Forgejo 的生态路线不同
SourceHut	Unix/FOSS、极简主义开发者	非常强调开放标准、邮件工作流	与 GitHub 工作流差异较大
Bitbucket	Atlassian 用户	Jira/Confluence 集成	商业平台，同样存在供应商依赖

然后就是 Codeberg

如果你只是想：

“我有一些开源项目，不想把所有鸡蛋都放在 GitHub 一个篮子里。”

那么 Codeberg 是目前非常值得尝试的方案。

它背后的 Codeberg e.V. 是一个非营利组织，平台基于 Forgejo，并且明确强调自由软件、社区治理以及非商业化。

这和普通商业 SaaS 的逻辑不太一样。

Codeberg 的核心价值并不是：

“我们比 GitHub 多几个按钮。”

而是：

“你的代码应该属于你，而不是属于某一家公司的平台。”

这是一种完全不同的价值判断。

Codeberg 真正吸引我的地方，不是它长得像 GitHub

Codeberg 的使用方式对于 GitHub 用户并不陌生。

你仍然可以：

• 创建 Repository
• Clone
• Commit
• Push
• Issue
• Pull Request
• Wiki
• Release
• Git LFS
• CI/CD
• Pages

甚至可以继续使用标准 Git 客户端。

也就是说，迁移的成本并没有想象中那么高。

更重要的是，Codeberg 的底层使用 Forgejo。

而 Forgejo 可以自行部署。

因此这里形成了一条非常有价值的路线：

Codeberg → Forgejo → 自建 Forgejo

而不是：

某个 SaaS → 另一个 SaaS → 再寻找下一个 SaaS

这就是区别。

但 Codeberg 也不是 GitHub 的完全替代品

这一点必须说清楚。

如果你需要 GitHub 巨大的开发者生态、第三方 App、企业集成、Marketplace、各种成熟的自动化服务，那么 Codeberg 目前显然不能完全替代 GitHub。

GitHub 最大的护城河从来不只是 Git。

而是生态。

所以最合理的策略并不是：

“从今天开始彻底不用 GitHub。”

而是：

“不要让 GitHub 成为唯一选择。”

一个更合理的开发者基础设施

我更推荐这样的架构：

                    ┌── GitHub
                    │
Local Git ──────────┼── Codeberg
                    │
                    └── Self-hosted Forgejo

本地始终保留完整 Git Repository。

重要项目至少拥有两个远程仓库。

例如：

git remote -v

得到：

origin    git@github.com:username/project.git
backup    git@codeberg.org:username/project.git

然后：

git push origin main
git push backup main

甚至可以进一步自动化：

git push --all origin
git push --all backup

git push --tags origin
git push --tags backup

这样 GitHub 今天发生故障，你并不会突然失去整个项目。

Codeberg 发生故障，也不会造成同样的问题。

这才是我们真正应该追求的东西：

Failure Independence。

故障发生了。

但你的开发工作没有停止。

更进一步：不要只备份 Git

真正成熟的灾备还应该考虑：

Source Code
    ↓
Git Repository
    ↓
Issues / PR
    ↓
CI/CD
    ↓
Packages
    ↓
Release Artifacts
    ↓
Deployment
    ↓
Secrets / Credentials

如果你的 GitHub 挂了，而 Docker Image、Release Binary、CI 配置、部署密钥全部也在 GitHub 上，那么一个 Git Mirror 实际上救不了你。

所以对于生产项目：

代码冗余只是第一步。

真正需要的是整个软件供应链的冗余。

为什么我仍然愿意推荐 Codeberg？

不是因为 Codeberg “一定不会宕机”。

这是一个非常重要的区别。

任何互联网服务都可能宕机。

Codeberg 也可能宕机。

真正让我觉得它值得推广的是：

它试图把“平台”重新建立在开放的软件和社区之上。

Codeberg 使用 Forgejo。

Forgejo 可以自托管。

Codeberg 也提供 Pages、CI 等服务。

因此即使未来你不想继续使用 Codeberg，你依然有迁移路线。

这比“所有东西都必须留在某一家公司的云上”更加健康。

开发者真正应该避免的不是 GitHub

而是：

只有 GitHub。

不要把问题理解成：

GitHub vs Codeberg

更应该理解成：

Centralization vs Resilience

GitHub 可以继续用。

Cursor 可以继续用。

各种 AI Agent 也可以继续用。

清华镜像、其他国内镜像也可以继续用。

真正需要改变的是开发者自己的基础设施思维：

不要因为一个平台很好用，就让它变成唯一的平台。

Git 的伟大之处，本来就是分布式。

也许我们应该把这种思想从 Git Repository 扩展到整个软件开发流程。

最后

如果你只有一个个人开源项目，现在就可以做一个非常简单的实验：

把它同时放到 GitHub 和 Codeberg。

不需要迁移。

不需要删除 GitHub。

不需要重新学习一套复杂系统。

只需要增加一个 remote。

然后你会发现：

所谓“平台选择”，其实不应该是二选一。

真正成熟的开发者基础设施，应该允许任何一个平台在某一天突然不可用，而你依然可以继续写代码。

这或许才是 Codeberg 最值得被更多开发者认识的地方。

不是因为它能够成为“下一个 GitHub”。

而是因为它提醒了我们：

GitHub 本来就不应该成为唯一的 GitHub。