最近几天开发者社区连续遇到几类很容易让人产生共鸣的问题GitHub 出现大规模故障平时用来缓解依赖获取问题的镜像服务也可能出现同步或访问异常而越来越多依赖云端的 AI 编程工具也开始进入开发者的日常工作流。单独看每一次故障都可以解释成一个普通的技术事故。但如果把它们放在一起看会发现一个更值得警惕的问题我们正在把越来越多的软件开发工作交给少数几个平台。而且这种依赖正在变得比以前更深。Git 在本地但软件开发已经不在本地很多开发者会说“Git 是分布式的GitHub 挂了我本地还有代码。”这句话技术上没有错但现实中的软件开发早已经不只是git commit和git push。一个现代项目通常还依赖GitHub/GitLab 上的 IssuePull RequestCode ReviewCI/CDReleasePackage RegistryContainer RegistryWebhookSecretsActionsBotOAuth 登录文档和 WikiAI 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各类开源项目源码但它并不能替代IssuePull RequestCode ReviewCIRepository 权限项目社区Release 管理开发者身份所以镜像是冗余的一部分但不是完整的代码基础设施冗余。那么 GitHub 的替代品有哪些其实不少。1. GitLab如果你需要完整的企业级 DevOps 平台GitLab 依然是非常强的选择。它不仅仅是 Git Hosting还包括 CI/CD、Registry、安全扫描以及大量团队协作能力。问题也很明显它很强但也很重。如果只是想给自己的开源项目找一个 GitHub 替代品部署一套完整 GitLab 往往属于杀鸡用牛刀。2. GiteaGitea 是非常成熟的轻量级 Git Forge。它最大的优势就是简单。如果你有一台 VPS希望自己掌握代码托管服务Gitea 是很自然的选择。3. Forgejo如果现在重新选择一个自建 Git Forge我更倾向于关注 Forgejo。Forgejo 是自由软件可以自己部署而 Codeberg 本身就是建立在 Forgejo 之上的平台。这意味着一个非常重要的事情Codeberg 不是一个必须永久依赖的黑盒 SaaS。你可以使用 Codeberg。也可以运行自己的 Forgejo。甚至可以在未来从一个 Forgejo 实例迁移到另一个 Forgejo 实例。这才是真正意义上的可迁移性。4. SourceHutSourceHut 是另一个非常有意思的选择。它的设计哲学和 GitHub 很不一样更强调 Git、邮件列表和 Unix 风格的开发流程。如果你喜欢极简工具链它值得研究。但如果你已经习惯 GitHub 的 Pull Request、Web UI 和现代协作方式那么它的学习成本会明显高一些。表格对比平台更适合谁核心优势主要问题Codeberg个人、FOSS、独立开发者非营利、Forgejo、社区驱动生态和 GitHub 仍有明显差距Forgejo 自建团队、公司、极客真正掌握基础设施自己负责运维GitLab中大型团队CI/CD、DevSecOps、企业功能完整重运维成本高Gitea自建、小团队轻量、成熟与 Forgejo 的生态路线不同SourceHutUnix/FOSS、极简主义开发者非常强调开放标准、邮件工作流与 GitHub 工作流差异较大BitbucketAtlassian 用户Jira/Confluence 集成商业平台同样存在供应商依赖然后就是 Codeberg如果你只是想“我有一些开源项目不想把所有鸡蛋都放在 GitHub 一个篮子里。”那么 Codeberg 是目前非常值得尝试的方案。它背后的 Codeberg e.V. 是一个非营利组织平台基于 Forgejo并且明确强调自由软件、社区治理以及非商业化。这和普通商业 SaaS 的逻辑不太一样。Codeberg 的核心价值并不是“我们比 GitHub 多几个按钮。”而是“你的代码应该属于你而不是属于某一家公司的平台。”这是一种完全不同的价值判断。Codeberg 真正吸引我的地方不是它长得像 GitHubCodeberg 的使用方式对于 GitHub 用户并不陌生。你仍然可以创建 RepositoryCloneCommitPushIssuePull RequestWikiReleaseGit LFSCI/CDPages甚至可以继续使用标准 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 gitgithub.com:username/project.git backup gitcodeberg.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 ResilienceGitHub 可以继续用。Cursor 可以继续用。各种 AI Agent 也可以继续用。清华镜像、其他国内镜像也可以继续用。真正需要改变的是开发者自己的基础设施思维不要因为一个平台很好用就让它变成唯一的平台。Git 的伟大之处本来就是分布式。也许我们应该把这种思想从 Git Repository 扩展到整个软件开发流程。最后如果你只有一个个人开源项目现在就可以做一个非常简单的实验把它同时放到 GitHub 和 Codeberg。不需要迁移。不需要删除 GitHub。不需要重新学习一套复杂系统。只需要增加一个 remote。然后你会发现所谓“平台选择”其实不应该是二选一。真正成熟的开发者基础设施应该允许任何一个平台在某一天突然不可用而你依然可以继续写代码。这或许才是 Codeberg 最值得被更多开发者认识的地方。不是因为它能够成为“下一个 GitHub”。而是因为它提醒了我们GitHub 本来就不应该成为唯一的 GitHub。