从 GitHub 搬到 Codeberg，原来没那么难——但真正的门槛藏在 CI 里
当开发者开始认真考虑“离开 GitHub”
这些年，GitHub 几乎成了开源世界的默认地板。你想托管代码，去 GitHub；你想看项目活不活跃，去 GitHub；你想提 Issue、发 PR、查 Release，还是 GitHub。它太方便了，以至于很多人早已把“代码托管平台”和“GitHub”画上了等号。
但最近，一位开发者在博客里写下自己把部分仓库从 GitHub 迁移到 Codeberg 的经历，语气很朴素，甚至带点“懒人教程”的味道：他原以为这件事会很麻烦，Codeberg 也可能还不够成熟，所以一直拖着没动。真正开始动手后，他发现事情没自己想得那么糟，尤其是最表层的那部分——仓库导入、Issue、Pull Request、Release 以及相关附件，Codeberg 已经能相当顺畅地接住。
这其实是个很有意思的信号。过去开发者讨论“逃离 GitHub”时，语境常常带着情绪：担心平台锁定、担心微软式中心化、担心开源社区被单一商业平台拿捏。但情绪要变成行动，前提是替代方案得“够用”。Codeberg 之所以值得关注，不是因为它喊出了某种口号，而是因为它开始让迁移这件事，变得不再像一次宗教仪式，而更像一次正常的基础设施更换。
迁仓库不难，难的是迁走习惯
按照这位开发者的描述，Codeberg 的仓库导入功能对 GitHub 用户很友好。Issue 编号、标签、作者信息都能保留下来，界面也和 GitHub 相似。对于经常处理项目迁移的人来说，这种“相似”一点都不低级，反而很重要。迁移最大的敌人不是功能缺失，而是认知摩擦：你每多花 5 秒找一个按钮，心里的退堂鼓就会更响一点。
更妙的是，这种体验直接对准了 GitHub 最强的一层护城河：不是代码仓库本身，而是围绕仓库长出来的一整套协作行为。开源项目不是一堆 commit 的堆积，它是讨论、争议、修复、发布、反馈的连续现场。如果只能迁代码，迁不了上下文，开发者就像搬了家却把门牌号和通讯录全丢了。Codeberg 现在至少在“历史上下文保留”这件事上，给出了一个合格答案。
如果项目还用到了 GitHub Pages，Codeberg 也提供了 codeberg.page 这样的静态托管方案，使用方式接近早期 GitHub Pages：把 HTML 推到指定分支即可。博客作者也提到，这项服务虽然没有严格的可用性承诺，但实际使用里并没遇到明显宕机。说白了，对个人博客、文档站、小型项目主页来说，它已经够用了。这里的关键词不是“完美替代”，而是“先跑起来”。对很多长期被迁移成本劝退的人来说，这一步尤其关键。
真正卡脖子的，不是代码托管，而是 CI
如果说前半段还有点“原来这么简单”的轻松感，那到了持续集成这部分，现实就开始露出牙齿了。作者直言，最难看的部分就是 CI。原因也很直接：GitHub 在这件事上做得太成功了。它不仅有成熟的 GitHub Actions，还有面向公共仓库几乎无限量的计算资源，以及对 macOS runner 这类稀缺环境的免费支持。很多项目平时没感觉，一旦想迁走，才会发现自己依赖的不是 Git 托管，而是一整座云端流水线工厂。
这正是今天开源基础设施最微妙的悖论。GitHub 表面上是个代码平台，实际上已经把构建、测试、分发、文档发布、自动化治理全包圆了。开发者在上面待久了，会天然把这种便利当作“理应如此”。但问题是，真正“理应如此”的东西，通常不会只掌握在一家商业公司手里。你享受免费算力时，某种平台依赖也在同步累积。到了想走的时候，账单不是用钱付，而是用迁移复杂度来付。
博客作者最后给出的建议很务实：如果你从 GitHub Actions 迁来，优先考虑 Forgejo Actions，而不是 Codeberg 另一套更稳定的 Woodpecker CI。理由很简单，Forgejo Actions 的界面和 YAML 语法都更像 GitHub Actions，连现有 action 生态很多都还能接着用，只是把 uses: 的地址改成完整 URL。这种熟悉感非常重要，因为多数开发者并不想在搬家时顺便重学一套 CI 哲学。
但即便如此，macOS runner 这类资源还是很难平替。作者甚至建议，如果项目强依赖 macOS 构建，不如保留 GitHub 端的 Actions，Codeberg 做主仓库，再把提交镜像到 GitHub 上跑构建，然后把状态同步回去。这个方案听起来有点绕，甚至有点“搬家了但快递地址还留在前任家”，可它很真实。开源世界很多基础设施决策，从来不是优雅第一，而是能不能活下来第一。
为什么这件事在 2026 年尤其值得看
把时间拉长一点看，Codeberg 的意义并不只是“又一个 GitHub 替代品”。它背后代表的是一种老问题的新解法：开源项目究竟该不该把命脉完全交给中心化平台？这几年，围绕 GitHub 的争议从来没断过——从平台治理，到 AI 训练语料，再到商业平台对开源协作规则的塑形。很多人嘴上说分散风险，身体却很诚实地继续把仓库、文档、CI、Pages、包管理和社交影响力全放在同一个篮子里。
Codeberg 之所以吸引一部分开发者，不仅因为它基于自由软件 Forgejo，也因为它让“非 GitHub 的协作方式”重新有了存在感。它未必能在体量上挑战 GitHub，但它能在价值观上提供一个出口：你不需要把每一个开源项目都放进商业平台的增长逻辑里。对于一些重视自治、重视社区控制权、或者只是单纯想降低平台锁定风险的项目来说，这一点相当重要。
不过，我也不想把这件事写成一曲“去平台化赞歌”。因为现实是，大多数项目最终看重的还是效率，而不是姿态。GitHub 的真正优势，除了产品成熟，更在于它形成了网络效应：开发者账户在这儿，贡献记录在这儿，自动化工具在这儿，招聘方和投资人也在这儿。你迁出 GitHub，技术上可能已经可行，社会关系上却未必能同步迁走。开源世界说到底也是个社交系统，而社交系统的迁移成本，往往比技术系统还大。
GitHub 不会轻易输，但替代者已经不是摆设
这篇迁移经验还有个很接地气的部分：旧仓库怎么办？作者选择更新 README，然后直接归档 GitHub 仓库。这是个相当理性的处理。因为如果你继续双向维持活跃镜像，用户还是会在 GitHub 上提 PR、留评论、开 Issue，结果就是两头冒烟。更麻烦的是，GitHub 的 PR 功能没法像 Issue 那样简单关掉，社区交互会继续在旧址发生，最后形成管理混乱。
这一点其实也暴露了平台迁移最尴尬的部分：技术上可以复制仓库，社区习惯却没法一键导出。很多开源维护者最终不是输给“不会迁”，而是输给“迁了之后还得解释十遍”。你可以想象那种画面：README 上大写着“项目已迁移到 Codeberg”，但还是有人熟练地在 GitHub 点开 New Issue，仿佛任何别处都不存在。这不是用户故意添乱，而是 GitHub 已经被训练成了默认入口。
所以，Codeberg 眼下最现实的价值，不一定是把所有人都从 GitHub 拉走，而是给开发者一个真正能落地的第二选择。以前很多人对替代平台的印象停留在“理念很好，但用起来像在修自行车”；现在情况开始变化了。至少在仓库迁移、Issue/PR 保留、Pages 托管这些关键体验上，Codeberg 已经不像试验品，更像一个能承担生产任务的正式选项。
而更深一层的问题也随之浮出水面：如果未来越来越多开发者意识到自己依赖 GitHub 的，其实是 CI 算力和生态黏性，而不是代码托管本身，那下一轮竞争可能就不会发生在“谁能托管 Git 仓库”，而会发生在“谁能提供更可信、更开放、更低锁定的开发流水线基础设施”。到那时，GitHub 面对的对手，未必只是另一个代码网站，而可能是一整套重新设计的开源协作栈。
说到底，这场迁移故事最打动我的地方，不在于它多么惊天动地，而在于它很诚实。它没有把迁移写成一场技术革命，而是承认：有些地方确实已经够好，有些地方还是难，特别是 CI。恰恰是这种不神化替代方案的表达，反而让人相信，开源世界正在慢慢长出真正可用的备份路线。不是所有人今天就要搬家，但至少，门已经不像以前那样焊死了。