告别 GitHub，投奔 Forgejo：一位开发者的自托管迁移实录

原文来源：Migrating from GitHub to Forgejo - Chris Smith — 从 GitHub 迁移到自托管 Forgejo 的完整实录，讨论数字主权与技术选型。

引言

2026 年 4 月，开发者 Chris Smith 发表了一篇名为 《Migrating from GitHub to Forgejo》 的博客，详细记录了他将代码从 GitHub 迁移到自托管 Forgejo 的全过程。

他的动机直白而有力：不是因为 GitHub 的宕机频率，而是因为谁控制着你的代码。

在 Hacker News 上，这篇文章引发了激烈的讨论。支持者认为这是"数字主权"的必然选择，反对者则认为"从一个依赖换到另一个依赖"并没有实质改变。但无论立场如何，一个事实是清晰的——越来越多的开发者正在认真考虑 GitHub 的替代方案。

GitHub 的问题

1. 可靠性：零个九

Chris Smith 写道："如果按最悲观的方式计算，GitHub 的可靠性是'零个九'。如果按最乐观的方式，他们有一个九——也就是每天大约 30 分钟的宕机时间。"

那个每个 GitHub 用户都见过的 独角兽页面（Error 500 页面）已经成为开发者社区的一个文化符号——但不是好的那种。

2. AI 强行嵌入

GitHub 在所有地方强行集成 Copilot，用户没有选择退出的自由。对于很多开发者来说，这种"我买了一个代码托管平台，结果得到了一个强塞的 AI"的体验令人不快。

3. Actions 质量下降

• 官方 Action 维护不到位：GitHub 没有时间维护官方的 GitHub Actions
• Copilot 质量堪忧：那些被维护的 Actions 中，Copilot 生成的代码"跑得乱七八糟"
• 运行缓慢：Actions 的执行速度在下降
• 奇怪的瞬态故障：越来越多的莫名其妙失败
• 安全漏洞：Chris 写道："当我起草这篇文章时，又有一个远程代码执行（RCE）漏洞被报告了。细节令人印象深刻……以全局共享的 git 用户身份执行代码，可以访问节点上的所有其他仓库。没有沙箱，没有容器，它直接以 git 用户运行。"

4. 微软收购后的方向

2018 年微软收购 GitHub 时，很多人就预测了最终的结果。八年后，这些预测正在成为现实。GitHub 正在被整合到微软的生态系统中，作为开发者的利益正在退居其次。

Forgejo：Gitea 的"觉醒"分叉

Forgejo 是 Gitea 的一个分叉（fork），但并非简单的复制。分叉者做了一些激进的事情：

• 增加了测试覆盖：Gitea 项目缺乏足够的测试，Forgejo 修复了这个问题
• 确保社区运营：Forgejo 承诺永远由社区运营，不为商业利益扭曲产品方向
• 彻底开源：没有"开放核心"之类的商业妥协

截至 2026 年，Forgejo 的功能已经非常成熟：

• ✅ GitHub Actions 兼容的 CI/CD 流水线
• ✅ 完整的 Issue 和 PR 管理
• ✅ 代码审查工作流
• ✅ Git LFS 支持
• ✅ Webhook 和 API
• ✅ 组织和团队管理
• ✅ 自托管或公共托管实例

迁移架构

Chris Smith 的迁移方案使用了 Tailscale + Docker 的组合：

1. Docker 部署

version: '3.8'
services:
  forgejo:
    image: codeberg.org/forgejo/forgejo:7-rootless
    ports:
      - "2222:2222"
      - "3000:3000"
    volumes:
      - forgejo_data:/data
    environment:
      - FORGEJO__server__DOMAIN=git.example.com
      - FORGEJO__server__SSH_PORT=2222
      - FORGEJO__repository__signing__SIGNING_NAME=Your Name
      - FORGEJO__repository__signing__SIGNING_KEY=your-gpg-key
    restart: unless-stopped

2. Tailscale 网络

Chris 没有将 Forgejo 暴露到公网，而是通过 Tailscale 的私有网络访问：

{
  "TCP": {
    "22": { "TCPForward": "forgejo:2222" },
    "443": { "HTTPS": true }
  },
  "Web": {
    "${TS_CERT_DOMAIN}:443": {
      "Handlers": {
        "/": { "Proxy": "http://forgejo:3000" }
      }
    }
  },
  "AllowFunnel": {
    "${TS_CERT_DOMAIN}:443": false
  }
}

这样他可以从任何设备安全地访问 Forgejo，而无需暴露到公网。

3. 镜像策略

为了不脱离开源社区，Chris 设置了 GitHub 镜像：

Forgejo (主仓库) -> Git push -> GitHub (只读镜像)

这样既拥有数字主权，又不会让开源贡献者找不到项目。

迁移步骤

1. 在 Forgejo 创建仓库
2. 从 GitHub 拉取所有分支和标签
3. 更新本地 git remote URL
4. 配置 GitHub 镜像
5. 更新 CI/CD 流水线到 Forgejo Actions
6. 更新项目文档中的仓库链接

Chris 的帖子中没有详细说明 CI/CD 流水线的具体迁移步骤，但他的总体建议是：Forgejo Actions 与 GitHub Actions 兼容，大多数工作流只需修改触发器和仓库引用即可。

适合谁？

✅ 推荐迁移的人群

• 隐私意识强的开发者：不想让微软看到你的代码
• 对 GitHub 可靠性不满的用户：独角兽页面已经受够了
• 小团队：10 人以下团队，自托管的运维成本可控
• 开源项目维护者：希望减少对单一平台的依赖

❌ 不适合迁移的人群

• 大型企业团队：Forgejo 的企业功能不如 GitHub 成熟
• 重度依赖 GitHub Actions 生态的团队：虽然兼容，但第三方 Action 的可用性不如 GitHub
• 不愿承担运维工作的人：自托管需要时间投入
• 需要高可见度的开源项目：GitHub 的社区效应仍然是最大的

HN 上的争论

这篇文章在 Hacker News 上引发了 100+ 条评论，核心争论点有两个：

论点一："这不是真正的去中心化"

"GitHub 的问题在于它是一个单一依赖。Forgejo 也是一个单一依赖。你只是换了一个不同的供应商锁定。"

支持方回应：Forgejo 是开源的，你可以 fork 它，可以贡献代码，可以影响产品方向。这与 GitHub 这种"你只能用我们给你的功能"的商业产品有本质区别。

论点二："运维成本被低估了"

"迁移仓库很容易，但迁移整个项目表面（Issues、PR、Wiki、Actions）才是困难的部分。"

Chris 承认这一点，但他的方案（通过 Tailscale 简化网络管理 + Docker 简化部署 + 镜像到 GitHub 保持可见性）已经大大降低了运维负担。

结语

Chris Smith 的故事并非孤例。在 Hacker News 的"最佳链接"页面上，"离开 GitHub 转向 Forgejo" 和 "I moved my digital stack to Europe" 等文章同时上榜，说明开发者对数字主权的关注度正在上升。

Forgejo 可能不会取代 GitHub——就像 Linux 桌面没有取代 Windows 一样。但对于那些真正关心"谁拥有我的代码"的开发者来说，Forgejo 给出了一个有力的答案：你自己。