从 GitHub 迁移到 Codeberg，懒人专用

Source: Hacker News

2025‑09‑06

我刚开始把一些仓库从 GitHub 迁移到 Codeberg。很久以来我一直想这么做，但因为觉得 Codeberg 还不够成熟，迁移过程会有很多（枯燥的）工作而一直搁置。结果发现这只在一定程度上成立，而且很大程度上取决于你的项目。如果你和我处境相似，希望这些笔记能成为动力和起点。这些方案未必是我长期会坚持的，但它们是我认为在从 GitHub 迁移时最容易上手的办法。

导入 Issues、Pull Requests 和 Releases

最简单的部分是迁移 issue、pull request 和 release 以及它们的产物。Codeberg 提供了一个直接从 GitHub 导入仓库的功能，而且运行良好，这些功能的 UI 与 GitHub 几乎相同。导入会保留 issue 编号、标签和作者信息。用户体验也比人们用来把其他 issue 跟踪系统导入 GitHub 的那些极其尴尬的 hack 要好得多。

GitHub Pages 替代方案

如果你使用 GitHub Pages，可以改用 codeberg.page。有提示称它不提供任何正常运行时间 SLO，但我没有遇到过宕机，目前使用还算不错。你把 HTML 推送到某个分支，方式与旧版 GitHub Pages 十分类似。

更新 2025‑09‑22: 另外你也可以尝试 grebedoc.dev 或 statichost.eu。

CI 考量

最棘手的部分是 CI。GitHub 通过免费 macOS runner 和对公共仓库的无限容量，成功吸引了大量用户¹。这两项你都必须放弃。我建议研究一下针对你的编程语言的交叉编译，并自行托管 Forgejo Actions 的 runner 来分别解决这些问题。

为什么选择 Forgejo Actions（而不是 Woodpecker CI？）

是的，Codeberg 上的 Woodpecker 已经相当稳定，但 Forgejo Actions 对于熟悉 GitHub Actions 的人来说更为亲切。UI 和 YAML 语法几乎相同，现有的 actions 生态系统大多数可以直接在 Codeberg 上使用。例如，我的 GitHub Actions 工作流写的是

uses: dtolnay/rust-toolchain

而我的 Forgejo Actions 工作流只需要改成

uses: https://github.com/dtolnay/rust-toolchain

如果你真的需要 macOS runner，可以继续在 GitHub 仓库上使用 GitHub Actions，将所有提交从 Codeberg 镜像回 GitHub，并让 Forgejo Actions 轮询 GitHub API，把 CI 状态同步回 Codeberg。我还没有尝试过这种方式，但我尝试过其他提供 macOS 构建的 CI 服务，它们并没有比 GitHub Actions 更容易或更干净地集成到 Codeberg。

处理 GitHub 上的旧仓库

最后，旧的 GitHub 仓库该怎么处理？我已经更新了 README 并将仓库归档。

你可以让 Codeberg 向 GitHub 推送新提交，这样用户仍然可以在 GitHub 上提交 PR、对 issue 和提交进行评论²。有些人通过在 GitHub 仓库上关闭 issue 来应对，但这是一种破坏性的操作，会导致所有 issue 返回 404，且 pull request 不能被关闭。某些仓库（例如 libvirt/libvirt）已经编写了一个 GitHub Action，能够自动关闭所有 pull request。

这种做法会对自托管和更广泛的软件生态系统产生严重负面影响，因为人们没有动力去优化构建或减少从你网站下载 release tarball 的频率。¹

你可能仍希望在过渡期间维护一个只读镜像，或者继续使用 GitHub Pages 和 GitHub Actions。²