GitHub → Codeberg：我的迁移经历
由于任务看似艰巨，我的焦虑让我拖延了很久，但最终发现其实工作量不大。我写下这段经历，正是希望让其他人知道：或许也能帮助他们克服自己的焦虑。
本文将分享我切换代码托管平台的过程及成效。
剧透预警：您正在阅读的这个网站已不再由GitHub Pages托管！目前我认为迁移已成功完成。但这并非点击一个按钮就能实现，下面将详细说明我的具体操作步骤。希望这能为他人提供参考案例，证明整个过程其实并不复杂。
(我的)迁移流程
首先花约一小时设置了个人头像、邮箱地址、SSH密钥等信息…
步骤1：迁移代码仓库
这一步并不困难，因为Forgejo(Codeberg背后的代码托管平台)提供了“从GitHub迁移”功能。你需要在GitHub上生成PAT才能导入问题等内容(这点很棒！)，而且还能加速迁移过程。
不过这个过程确实很繁琐，因为完全需要手动操作(或许存在自动化方案，比如使用某些Forgejo命令行工具，但我没去研究)。此外，受限于GitHub API速率限制，每次尝试同时导入两个仓库时，总有一个或两个会失败。(不过影响不大，因为在导入过程中我仍可继续填写迁移页面；通常填写所需时间与Codeberg执行导入的时间大致相当。)
最令人欣喜的是问题、PR、维基和发布记录均能完美迁移：这意味着我终于可以彻底告别GitHub了！
第二步：将链接指向Codeberg
虽然无法控制所有指向我项目的链接，但至少能在个人目录运行rg -F github.com/ISSOtm命令，处理自有仓库内的链接。替换过程可自动化实现：
$ sed --in-place --regexp-extended ‘s,github.com/ISSOtm,codeberg.org/ISSOtm,’ <files...>
若需批量替换目录内所有文件：
$ find <目录> -type f -exec sed -Ei ‘s,github.com/ISSOtm,codeberg.org/ISSOtm’ {} +
但仓库可能仍指向GitHub：
$ git remote -v
origin git@github.com:ISSOtm/rsgbds.git (fetch)
origin git@github.com:ISSOtm/rsgbds.git (push)
由于远程URL以文本形式存储，可手动执行git remote set-url origin git@codeberg.org:ISSOtm/rsgbds.git(HTTPS用户请替换协议)，或使用上述替换命令：
# 在单个仓库内：
$ find .git -name config -exec sed -Ei ‘s,github.com:ISSOtm,codeberg.org:ISSOtm,’ {} + # 使用HTTPS时请将冒号替换为斜杠！
# 处理当前目录下所有仓库：(Bash用户需先执行`shopt -s globstar`)
$ find **/.git -name config -exec sed -Ei ‘s,github.com:ISSOtm,codeberg.org:ISSOtm,’ {} + # 同上操作
…接下来只需将修改推送到所有仓库即可。
步骤3：创建GitHub仓库占位
我还希望明确表明我的仓库现已迁移至Codeberg，因此在空目录中创建了一个小脚本：
#!/bin/bash
set -euo pipefail
git remote set-url origin git@github.com:ISSOtm/$1
cat <<EOF >README.md
# 已迁移至 https://codeberg.org/ISSOtm/$1
[迁移原因详见我的博客](http://eldred.fr/blog/codeberg)
EOF
git add README.md
git commit --amend --message ‘添加迁移通知’
git push --force
gh repo edit --description “迁移至 https://codeberg.org/ISSOtm/$1” --homepage “https://codeberg.org/ISSOtm/$1”
gh repo archive --yes
然后运行脚本：
$ chmod +x stub_out.sh
$ git init
$ git remote add origin ‘’
$ ./stub_out.sh rsgbds
$ ./stub_out.sh fortISSimO
# ...等等
自动化让过程不再痛苦，进展相当顺利。
第四步：移植CI
现在进入更具挑战性的环节 🙂
首先注意到Codeberg的CI文档中这段内容：
运行 CI/CD 管道会消耗大量能源。尽管看到满屏绿色勾选标记令人欣喜，但任务执行会产生实际费用并造成环境成本。
与其他大型平台不同，我们不鼓励您编写“重量级”管道并在事后收费。我们期望您审慎权衡管道的成本效益，将 CI/CD 使用量控制在确保项目质量所需的最低限度。
这让我开始思考哪些项目真正需要持续集成，最终我决定： 我决定仅需为网站发布以及gb-starter-kit和fortISSimO的文档配置CI； 其余项目本就无人贡献，暂时不配置CI也无妨。
实际上，Codeberg提供了两种CI方案：Woodpecker和Forgejo Actions； 前者功能更强大但需申请权限，后者则与GitHub Actions高度相似，便于迁移。因此我选择了Forgejo Actions，尽管它标注为测试版。
将YAML文件从GHA迁移至Forgejo Actions并不复杂； 例如可参考gb-starter-kit发布CI的迁移提交。(由于我移动了文件，此处不会显示差异，但修改量很小，手动对比很方便。)
以下是关键要点：
- Actions通常仅引用为
owner/repo，但Forgejo支持克隆 任何 Git仓库，尤其支持跨代码托管平台操作。实际建议始终使用完整URL，避免依赖默认前缀——该前缀由实例管理员配置，可能存在兼容性问题。 - 若
.github/workflows目录不存在，Forgejo会自动识别该目录，但个人认为将未迁移脚本保留在.github目录下，已迁移脚本存放于.forgejo更便捷。 - 大多数Actions(指单个步骤而非工作流文件)在Forgejo Actions上可直接使用。很棒！
- Codeberg 的运行器与 GitHub 有显著差异：默认安装的软件少得多，资源更有限，且仅提供 Linux 运行器(默认 Ubuntu，但可使用 任意 Docker 容器镜像)。由于 macOS 和 Windows 属于非免费操作系统，Codeberg 暂无计划提供这两种平台！出于理念和财务双重考量。若此限制不可接受，建议采用交叉编译方案或自带运行器。
- 若非低延迟关键需求，建议使用懒惰运行器以实现更优负载均衡及更环保的能耗。实际使用中延迟从未超过数分钟，对我而言完全可接受。
我曾额外投入时间尝试降低CI任务的计算资源消耗，部分动因是运行器体积较小，且推测选择更小型的运行器能加快任务调度速度。此处有一个相关提交； 特别注意第50行，我尝试1使用预装LaTeX的Docker镜像，既省去了apt install的时间，又减少了文件系统写入操作，从而释放内存。
1,遗憾的是，由于noweb版本不兼容，我不得不回退到基础Ubuntu镜像；但常规LaTeX工作流程本不会遇到此问题。
第五步：重新托管我的网站
前几步操作仅耗时数日；但由于我的网站(即本站)使用GitHub Pages托管，无法直接迁移其仓库(没错，是复数形式： 可单独配置仓库发布，例如https://eldred.fr/fortISSimO虽不在主仓库中仍能独立发布)。
理论上，Codeberg 提供类似功能的 Codeberg Pages；但正如该页面所述，由于复杂性和性能问题2，该功能背后的软件目前处于维护模式。于是我暂时搁置了这个问题约一个月，期待后续更新。此外，子项目是以子域名而非子目录形式发布的，这会导致链接失效(例如http://eldred.fr/fortISSimO将变为http://fortISSimO.eldred.fr)。唉……
后来(偶然间哈哈)我发现了git-pages及其公共实例Grebedoc3！它功能类似GitHub Pages，不过由于未集成在代码托管平台内，配置稍复杂些。
git-pages其实有不少亮点：
- 在整个迁移过程中，我的网站实现了零停机，因为 git-pages 支持 在更新 DNS 记录前上传网站！
- 它还支持服务器端重定向，例如可将访问http://eldred.fr/gb-asm-tutorial/*的用户引导至新地址。此前因我方客户端覆盖不全导致用户出现404错误的情况，现在彻底解决了！
- 它还支持自定义头部；我对CORS兴趣不大，但已通过该文件 表达敬意4。
对了，Codeberg的2025年11月通讯提到该平台计划逐步迁移至[git-pages]服务。令人振奋！
我实际使用体验远胜GitHub Pages；因此已加入Catherine的Patreon，期待这项服务能走得更远。
2,引用Catherine创建git-pages的初衷：我最初只想使用Codeberg Pages，后来发现该服务处于维护模式，其架构极其糟糕——不仅正常运行时间极低，还经常导致Codeberg的Forgejo实例崩溃。
3,🦃。它正紧盯着你……
4,此处提供背景说明以阐释其含义。
时间追踪
步骤1至3(仓库迁移)耗费了我大半个下午； 步骤4(移植CI)耗费我另一个下午，主要用于学习新CI系统；步骤5(网站)则……本应只需半天，但我借此机会清偿了技术债务(将幻灯片仓库合并至主网站)，因需重构架构而耗时数日。
总而言之，即便迁移了45个仓库，整个过程基本只花了一个周末。而且我完全不觉得烦！
由于任务看似艰巨，我的焦虑让我拖延了很久，但最终发现其实工作量不大。我写下这段经历，正是希望让其他人知道：或许也能帮助他们克服自己的焦虑。也许吧。:P
后续计划？
总体而言，我对这次迁移非常满意！据我所知，网站功能完好无损，而我在GitHub上也尽可能控制了破坏范围： 我截断了master分支，但其他所有分支和标签均保留(主要是偷懒啦)，永久链接(如https://github.com/ISSOtm/gb-bootroms/blob/c8ed9e106e0ab1193a57071820e46358006c79d0/src/dmg.asm)仍可正常访问，仅非永久链接(如https://github.com/ISSOtm/gb-bootroms/blob/master/src/dmg.asm)失效——不过这类链接本就不稳定。
既然这意味着所有代码 确实 仍存于GitHub，我 想 删除仓库；但当前这么做实属不智，毕竟会导致所有重定向失效。我会在…大概一年后再考虑此事。我也想注销GitHub账号(就像我注销Twitter账号那样…*含糊手势*)，但不仅需要保留仓库，还需通过该账号为仍驻留GitHub的项目贡献力量。
迁移的弊端在于：离开主流平台后，我的项目很可能获得更少的贡献…但原本贡献就不多，而且已有部分人注册了Codeberg账号继续参与我的项目。同样地，我也不太担心项目曝光度的问题。走着瞧吧哈哈 🤷♂️
最后说明：本文是在迁移完成后撰写的，过程中未做详细记录。若遗漏任何步骤，欢迎在评论区留言或提交问题，我会及时更新本文。
祝好！
本文文字及图片出自 GitHub → Codeberg: my experience
在这段迁移故事中真正令我印象深刻的，并非技术层面，而是它提醒我们“功能对等”并非真正的障碍。Codeberg已足以满足日常工作流程需求；它所缺乏的是GitHub通过网络效应、集成生态及惯性积累形成的引力场。
类似https://tangled.org的项目正在部分解决这个问题。它基于与bluesky相同的协议构建，意味着你的身份在不同平台间得以保留，因此你的Git托管位置与发现和连接他人的方式无关。
顺带一提，Forgejo(Codeberg)也在构建联合功能[0]。
[0]: https://codeberg.org/forgejo-contrib/federation/src/branch/m…
可惜它主要面向ActivityPub协议对吧？这意味着无法实现名称可移植性。相比Tangled这类基于AT协议的方案，这算是个 重大 缺陷。
我认为这与当前具体情况无关，但据我所知ActivityPub本身并不 本质上 阻碍名称可移植性。只是目前几乎所有实现都不支持该功能(Forgejo应该也不例外)。
当然，Tangled的实际缺陷还在于其网络效应仅限于ATmosphere内部——你依然无法触达GitHub用户。
首先，联合协议的非标准扩展历来成效惨淡。即便某项扩展达到中等普及率(我认为这种情况极为罕见)，其长尾采用率也极其低迷。对于像
其次，这怎么可能只是实现层面的扩展？当客户端不支持该扩展时，系统将彻底崩溃。要实现名称可移植性，客户端需要两步验证：先通过名称定位服务器，再连接该服务器。而当前机制(据我理解)是名称本身就代表服务器身份。这从根本上改变了协议层面的身份定义。
若有人对ActivityPub有更深入的了解，欢迎指正。但在该协议强制要求(且被广泛采用)类似SMTP的MX记录或ATProto等同机制之前，名称可移植性仍遥不可及。
我对规范并不精通，所以别把我的话当圣经，但据我理解，当前实现已经支持名称发现。问题在于所有实现都硬编码了服务器名称。据我所知，有人通过在自家服务器放置指向实例账户的.well-known文档来实现权宜之计，但若服务器未主动识别该标识符，这种方案仍很不稳定。不过(再次强调，若我理解正确)服务器 理论上 可通过更新/重写来完善支持。
恕我直言，这更像是权宜之计而非规范扩展，更遑论可行方案。我承认从纯技术层面看确实存在可能性，但在现实世界中真正可行？恐怕未必。
或许我忽略了某些细节，但若Mastodon决定在设置页新增域名输入框，并附带静态文件上传指引(例如放置于.well-known目录)，我完全不意外整个生态系统会随之效仿。
Nostr会更胜一筹。毕竟它是真正自由的协议，而AT协议背后有风投支持。
我不太认同Nostr这类加密密钥优先的协议——它将身份与密钥对紧密绑定。人类身份机制完全不同，以密钥对为基础的身份体系永远无法普及。
符合人类认知习惯的可读名称才是更理想的身份标识。而DNS名称算是这种理念的尚可实现方案。
我认为基于DNS提供名称可移植性的去中心化协议，远比依赖密钥对的方案更优越。
AT获得风投支持的说法有误——获得支持的是Bluesky公司。AT本身仅是用于签名、存储和传播结构化数据(记录)及记录所有者身份的规范。
那么规范内容的控制权在谁手中？依然是Bluesky。
并非如此。该规范对所有人开放参与。此外，Bluesky正致力于在IETF推动AT标准化[0][1]。他们还签署了专利非攻击性承诺：https://bsky.social/about/blog/10-01-2025-patent-pledge
简而言之，他们正积极推动AT实现最大程度的中立化。
[0]: https://docs.bsky.app/blog/taking-at-to-ietf
[1]: https://datatracker.ietf.org/doc/bofreq-newbold-authenticate…
要是能用类似gpg密钥的东西作为身份认证就好了。如果它能具备密钥共享、撤销、升级机制，还能与他人交叉签名构建某种类似网络的信任体系。我敢说我们完全可以围绕它构建一套基础设施，以完全去中心化的方式维护开发者身份。
是否有人详细比较过Tangled、Codeberg和GitHub？
我对Codeberg的主要痛点在于问题搜索功能欠佳。有时我确信某个问题存在——因为我曾处理过它——但用键盘搜索却难以找到。希望这方面能尽快改进。
虽然Codeberg整体性能曾多次明显下降，但最近已恢复正常。
若计划迁移含数百个问题的项目，建议先进行测试迁移，并通过多种搜索方式验证结果质量。
更关键的是海量的文档和示例资源。人人都在使用它，因此人人都在撰写相关文档，新员工很可能已掌握相关知识，即使不懂也能轻松查阅。
不过对于动作(actions)和整体CI/CD流程而言，情况或许没那么糟——无需整个团队精通编写方法，只需确保 至少 有一人掌握即可。而且这类知识通常并不难学。
这正是CI应与代码仓库存储分离，且两者都应独立于协作工具的原因。若需要，它们都可以使用Git协议。
> 这正是CI应与代码仓库存储分离的原因
或许吧，但复杂项目中各代码分支与CI仓库分支之间本就存在依赖关系。相比将CI代码置于仓库中使依赖关系显性化，我实在不确定这种分离方式能真正简化多少管理复杂度。
> 不过对于动作(actions)这类工具及常规CI/CD流程，这种做法倒未必糟糕
GitHub的CI/CD存在npm问题——大量微小组件被封装在动作中，用户从四面八方引入这些动作。GitHub的弃用周期相对较短，导致动作需要重写更新，即便对你而言毫无必要——在此情境下我认为，若非安全问题则无需如此。结果就是光是维持现有动作运行就耗费大量精力——若当初直接编写自有动作反而更省力——但这种省力正是GitHub的卖点之一。
或许我存在偏见，毕竟近二十年来我一直在处理复杂的CI/CD流程——但当你真正开始深度使用GitHub工作流时，其局限性会_极快_地暴露出来。
这似乎是个
<博弈论>问题(公地悲剧？先发优势？我不太熟悉这些概念)。任何公司不选择GitHub都可能是错误的，因为这会增加实现公司实际目标的阻力。但当足够多的公司为此付出代价时，最终将通过激发更强烈的竞争而惠及所有人。或许是协调问题？https://en.wikipedia.org/wiki/Coordination_game
这本质上是囚徒困境的变体。
Codeberg是Gitea的分支，而Gitea本身是Gogs的分支。
这两个分支都源于“哲学”原因而非技术因素，Joe Chen(GitHub用户@unknwon)凭借几乎独立完成的Go语言纯净代码仓库构建工作，理应获得极大赞誉。
> Codeberg是Gitea的分支，而Gitea本身是Gogs的分支。
Codeberg 是一个由 Forgejo 驱动的网站，而 Forgejo 是 Gitea 的分叉版本。
> 两者分叉的初衷均源于“理念”而非技术因素
Gitea 分叉是因为某位开发者独占 Gogs 仓库所有权且拒绝共享维护权限，此举更偏向“实用”而非“理念”。
Forgejo的分叉源于核心开发者秘密注册了Gitea商标及标志的公司。此举旨在夺回项目资产(名称/商标、标志等)的控制权。
这似乎是典型的“英雄殒落或恶棍长存”式行为，在同类项目中并不罕见。但愿Codeberg不会重蹈覆辙。
这正是我暂不加入Codeberg热潮的原因——尽管我对自建Forgejo兴趣浓厚。
不过我更期待看到另一种可能性——让仓库能在所有可能的集中式或自托管服务中被发现。我真正喜欢GitHub的地方在于，它总能不时为我发掘出值得关注的有趣项目和开发者。
需说明的是，Codeberg以“注册协会”形式运营并拥有慈善机构资质，因此属于非营利组织，其领导层必须由会员选举产生。KDE的KDE e.V.也采用类似架构。
你觉得多久后社区会因细微理念分歧分裂成“Codeberg人民阵线”和“Codeberg人民阵线”？
Codeberg应该会采用持续保持开源的forgejo分支吧。
Forgejo去年已重新授权为GPL3
他们为何不选AGPL真是个谜，不过至少保留了copyleft特性
分裂者！
注意到今天(及过去几天)首页多个项目正在迁离GitHub。
是否有近期事件或更广泛趋势能解释这种转变？
持续的可用性问题、微软强行植入AI、GitHub专注迁移至Azure基础设施而非功能开发和缺陷修复。如果非要猜测的话。
…用你的代码训练他们自己的模型…
只要你在任何地方发布代码，它就会被用于训练。微软并非仅限于训练GH托管的代码。
但他们并未限制自己仅训练许可宽松的代码。
两种极端情况——既开源又采用copyleft许可的代码都不应用于训练，但谁会听呢。
对于私有仓库，这个观点依然成立，而且我们不该让他们轻易得手。
他们不会训练私有仓库，反正至今没有证据证明过
> 只要你公开发布代码，它就会被用于训练
需要引用依据。首先他们得知道我的代码存在…还要耗费时间和流量爬取它——毕竟这代码肯定不会托管在Azure上…很可能被检测到并封禁。
无需引用依据。这应被视为恶意网络安全威胁的预设假想。
> 这应当被视为恶意网络安全威胁的预设情境。
若你相信线上资产能实现绝对网络安全，兄弟，我得告诉你真相：你唯一能做的就是提升防御难度，但绝不可能做到绝对不可破解。其防护程度取决于你愿意投入多少资源和承受多少损失。
同感。Codeberg的加固措施确实有效，这算是一种防护手段。
多数人根本不在乎AI是否利用其开源代码库进行训练。若真在意，微软宣布消息时他们早就集体迁移了。当前停机和性能问题显然才是真正的痛点。
这并非否定人们不该关注AI训练问题。我对他们宣布此事时的公众反应感到失望。GitHub的服务条款包含允许其使用你代码的条款，这会覆盖原始许可协议。更糟的是，即使有人从其他代码库镜像你的代码至GitHub，该条款依然有效。而且他们不止于此——我注意到他们以安全为名，直接从crates.io等源代码注册库抓取代码。若他们没把这些数据也用于AI训练，我才觉得意外。
我原本以为AI不过是昙花一现的潮流，因此并未在他们宣布时立刻离开(就像频繁更换发行版同样不可取)。这更像是青蛙终于意识到——温度确实升得太高了。
Zig的公告[0]或许能提供些线索
[0] https://ziglang.org/news/migrating-from-github-to-codeberg/
我个人对到处塞AI已经厌倦了，不过GitHub还算凑合——虽然它作为Rails网站时的表现明显优于现在这个React“应用”。
我猜这类似于“鲨鱼之夏”现象。https://en.wikipedia.org/wiki/Summer_of_the_Shark
不便点名，但据内部人士透露，GitHub当前内部政治斗争一片混乱，除P0级别项目外，平台大部分功能既无进展也遭弃置。
我怀疑GitHub——以及某种程度上整个微软——正经历一场信任跃层现象[1]。作为开源平台，GitHub长期以来积压着用户的不满情绪，但不足以让任何单个项目自行离开；然而随着时间推移，积怨已然爆发，多个项目认定这是最后一根稻草，如今通过HN首页正形成某种病毒式传播。
这场风波的实际规模尚待观察，但关于GitHub的种种疑虑我已思索许久。此外，Windows系统因AI/广告软件导致的体验恶化，以及Windows 10的强制弃用政策，恐怕也在当下为所有微软相关事物蒙上阴影。
[1] 最初提出该概念的推文串见https://threadreaderapp.com/thread/1588115310124539904.html。本文虽以数字媒体为背景，但其普适性不言而喻。若感兴趣，可查阅其他相关文章。
https://sfconservancy.org/GiveUpGitHub/ 内容稍显过时。当然，根本问题在于微软。
GitHub的新重心是为AI收集数据。
其他一切对他们都不重要。
坦白说，我一直在减少工作流程中微软开发工具的使用，因为他们沉迷于AI迷思，导致产品在其他所有方面的可用性和可靠性都受到影响。
工作上不得不使用Windows和Visual Studio 2022，但我已重新启用Sublime Text许可证，正考虑将个人仓库迁移至Codeberg。
Codeberg提供免费CI运行器吗？据我估算微软每年在免费GitHub CI上的支出超过1亿美元。这很可能是他们最大的成本项。Codeberg免费提供这种服务似乎并不合理。
文章引用了Codeberg的声明：
坦白说，提及环境成本很可能让用户望而却步。强调实际金钱成本尚属合理，但环境成本则不然——其危害程度相当于民众多购置几十辆汽车，而这种行为完全可能被汽车制造商和经销商的随机营销决策所左右。
根据我的经验，用环境成本说教来谴责技术达人根本行不通。更有效的方式是将问题转化为性能优化课题，这自然能激发工程师的兴趣。
影响真有这么小吗？持续集成中大量工作存在重复(例如
apt update && apt install texlive-full)，因此减少运行频率确实有益。另请参阅https://openssf.org/blog/2025/09/23/open-infrastructure-is-n…：
> 自动化CI系统、大规模依赖项扫描器以及临时容器构建(通常由企业运行)给基础设施带来巨大压力。> 这些商业级工作负载常在无缓存、无限流甚至无压力感知的情况下运行。
…这表明其负载不可忽视。
单独看确实不可忽视。但与运输行业相比就微不足道了。
你可以用Codeberg搭建自己的Woodpecker实例。我在工作和私人项目中都这么做，效果极佳，比Codeberg提供的免费CI服务快得多。
我对此很感兴趣——你参考了什么指南或在线教程吗？目前我使用Codeberg的免费CICD服务，但功能受限，更倾向于自建系统。
我参考了这份文档：https://woodpecker-ci.org/docs/administration/configuration/…
他们确实提供，但容量有限，需要申请访问权限并提供合理依据。
https://docs.codeberg.org/ci/
实际上这仅适用于Woodpecker实例。Forgejo Actions无需申请许可即可使用，并提供三层免费运行器(仅限Linux/仅限adm64)。
明白了，这很有意思。上次查阅文档时只看到自托管运行器的说明，但我会认真研究这个方案。
申请已经有一段时间了，但当时所谓的“合理理由”主要就是你的仓库是开源的，且包含许可证文件(外加对计划内容和资源消耗的模糊描述)。
对我来说这就是GitHub的护城河。
与其说是护城河，不如说是亏本促销。记得当年Travis CI也是免费的。
所以这座护城河其实是条向大海缓慢渗漏的沟渠，需要耗费高昂成本持续注水。
(我坚持用这个比喻，因为无论怎么称呼，它始终是我使用的主要阻碍。)
如果/当GitHub取消免费层级时，我大概率会流失用户。确实，免费服务是留住我的关键因素。
有没有性价比相当的Github替代方案？特别是对需要私有仓库的极小团队或独立开发者？这里作者特别提到Codeberg，但它似乎只适用于开源项目。
你可以自建Codeberg底层的Forgejo软件。此外还有功能更强大的GitLab，但维护成本可能更高。还有长尾项目，比如Forgejo的源头项目(Gitea和Gogs)，以及其他开源代码托管平台，例如从现已停用的Phabricator分叉而来的Phorge。
Forgejo相较Gitea的优势何在？
GitHub的核心价值不在技术层面——其网站体验糟糕透顶。关键在于社交网络功能。
这观点有趣。我本以为恰恰相反。虽然从未使用过社交功能，但技术层面(包括集成能力)才是核心价值所在。
它确实会崩溃停摆；GitHub支持团队更是令人头疼。不过基础托管和PR工作流尚可。
如果你不在乎堆叠的PR、不写代码审查、不阅读非简单审查、也不需要差异查看器，那PR流程确实没问题。
这些操作都该用IDE完成。那样体验好得多。
这些年网站界面越来越糟糕。变得臃肿迟缓，按钮布局也越来越随机。比如在仓库里搜索完内容后，要返回仓库首页竟要点击最出人意料的按钮。
虽然功能依然可用，但操作体验已不再愉快。
我认为Github的界面其实不错……只要内容能顺利加载。
这才是如今Github的症结所在。太多关键信息被延迟加载的转圈圈掩盖。尽管Codeberg服务器远在重洋彼岸，偶尔还会弹出反爬虫验证，但响应速度明显更胜一筹。
像Gitlab这样的竞争对手通过提供“Github登录”功能降低了使用门槛，因此已有Github账号的用户注册替代代码托管平台的成本很低。
我参与维护Codeberg上最热门的项目之一Fuzzel。可以说，在替代代码托管平台上我们从不缺乏问题反馈和功能请求——事实上，这些反馈源源不断！
社交网络的价值何在？我通过搜索引擎查找本语言的包来发现代码。无论是GitHub/GitLab/Gittea等平台都无所谓，只要被搜索引擎收录即可。
我喜欢Sourcehut。这是唯一不盲目模仿GitHub界面的代码托管平台，其操作体验流畅如本地运行。
我也欣赏它卓越的CI功能，但不喜欢以补丁/邮件为核心的协作方式。(尝试过，体验不佳。)
Sourcehut简直是为我量身打造的产品，完全契合我的需求，设计令人惊艳。但对于非开源团队而言使用难度较大——队友们可能会因界面差异而困惑。其补丁收发工具相当简陋，缺乏支持补丁功能的优质图形化邮件客户端。此外它也不支持组织管理，更无法像代码所有者文件那样实现最小访问权限原则。
界面响应虽快，但操作逻辑不易掌握——至少对新手而言如此。尤其当README未明确说明时，用户根本无法知晓如何提交错误报告、提交补丁或查看相关邮件列表存档。
> 尤其关键的是，除非README文件中明确说明，否则用户完全无法明确如何报告错误、提交补丁或查看相关邮件列表存档。
这些内容本应在README中说明。Sourcehut的各个组件——包括仓库前端、项目页面、邮件列表、任务列表、文档页面等——都是独立存在的。它们之间不存在像GitHub那样预先定义的关联方式。例如，我所有开源项目都共用一个邮件列表。
若GitHub能解决你的问题，就继续使用它。目前我看到的迁移理由无非是“不喜欢微软”和“不喜欢界面”。但总体而言，GitHub仍是该领域的技术领导者。对于开源项目，我理解部分人想迁移的动机；但商业项目使用它非常理想。最近Hacker News上涌现大量用户迁移的跟风文章(实际仅代表极少数用户)，除非你有充分理由选择其他平台，否则无需盲目跟风。
GitLab。若不喜欢云服务，也可选择在廉价服务器上自建部署。
遗憾的是，GitLab已不再符合我们的需求——它对合并请求(即PR)设置了最大尺寸限制，超出限制的内容根本不会显示在合并请求界面。
最近工作中就因此吃过亏：有个重要合并请求需要审核，但超过一半的内容在GitLab网页界面完全无法查看。
这是他们已知的一个(错误的)“功能”，且最早要到2027年才计划修复。
毋庸置疑，我们正在迁移并建议其他团队也这样做。
若追求性价比且使用免费GitHub Actions，则不推荐。
Azure DevOps：最多5名用户免费。免费运行器、免费私有仓库及工作项追踪功能。
我最近研究过这个问题，但没找到合适的解决方案。
我原本想找类似Migadu[1]的Git托管服务——便宜、私有且适用于个人用途。最佳方案可能是自建托管。
我在ASK HN论坛发帖征集方案但无人关注：https://news.ycombinator.com/item?id=46011054
目前已开始将新项目存入Codeberg。部分私有项目通过手动更新GCP上的私有镜像(现阶段免费)。
[1] https://migadu.com/pricing/
Gitlab相当不错，若真有需求还能自行部署。这家公司也很有意思，他们是100%远程办公模式。
Sourcehut[1]也是个值得关注的平台。
[1] https://sourcehut.org/alpha-details/
需注意Codeberg支持私有仓库。(本想链接我的仓库，但你会看到404错误啦 :P)
没错，但你仍不能用它们开发专有软件。这对多数商业软件开发团队而言毫无用处。
不能付费用于商业用途？
Bitbucket？
我一直想尝试自托管的Gittea。
我每天都要用Bitbucket。我的建议不仅是“不行”，而是“绝对不行”。
Bitbucket的推送和拉取速度极慢。从可靠性角度看，我遇到的Bitbucket问题远多于Github。其网页界面存在难以言喻的违和感——仿佛是事后仓促添加的旧系统皮肤，毫无匠心可言。更没有源代码搜索功能。
可能还有更多问题，但老实说我尽量避免接触Bitbucket仓库的网页界面，所以很乐意对其他缺陷保持无知。这实在可惜，因为我记得当年Bitbucket还是Mercurial的Github，界面虽借鉴他人但相当不错，而且允许用户免费创建私有仓库。
如今Bitbucket已弃用Mercurial，Github也开放了私有仓库。面对这样的现实，2025年的TYOOL时代还有人选择Bitbucket，实在令我费解。
<s>据我所知，Codeberg并无强制开源要求。</s>此说法有误，我误读了服务条款的变更内容。
Codeberg要求托管的仓库必须是开源项目
https://codeberg.org/Codeberg/org/pulls/1219 现已失效。
根据现行服务条款：
因此服务条款规定仅支持开源软件的私有仓库，但又通过“小型个人项目”的后门条款放宽限制——该条款定义模糊且由Codeberg自行裁量，因此可能并非存放私人副业项目的理想场所。
你说得对，仔细思考后我认为这份服务条款比旧版更令人困惑。明确允许MIT许可软件(因该许可获OSI认证)反而更清晰。现在这种表述让人感觉若有人投诉或仓库过多，随时可能被彻底封禁。不过Forgejo本身是FLOSS项目，且提供免费托管服务，他们当然有权制定任何条款。我将删除前文评论，因其信息有误。
没关系，我也对此感到困惑。我迁移了一个更偏向“源代码开放”而非“开源”的仓库，事后才意识到这可能违反了服务条款。
作者的理由似乎合情合理(https://eldred.fr/blog/codeberg/)
但最终结果对用户似乎毫无改善？这让我有些失望(并非责怪作者)
维护者的收益也多是理念层面的…实在可惜
刚试用Codeberg平台
– 不断弹出“确认您不是机器人！”的动漫女孩验证
– GitHub登录按钮藏在微小的下拉箭头里，疑似故意隐藏…要么清晰展示选项，要么干脆取消
– 界面格式与GitHub如出一辙，布局毫无改进。项目说明文档依然置于底部，用户必须滚动浏览海量文件才能了解项目内容。例如：https://codeberg.org/dnkl/foot。为何不直接将README设为首页，文件树另设标签页？或者采用横向并排布局
盲目复制市场领导者却毫无创新…这似乎不是制胜策略？要么是缺乏想象力，要么是缺乏主动性。这个领域显然存在巨大的改进空间…
> 我总收到“确认您不是机器人！”的动漫女孩提示
那是阿努比斯：
https://anubis.techaro.lol/
另有无品牌版本可供选择，付费层级支持图片定制：
https://anubis.techaro.lol/docs/admin/botstopper
目前唯一大规模部署的同类方案是Cloudflare的。
Codeberg倾向于开放非中心化方案合情合理。
付费才能用无品牌版？这算什么开放？搞不懂。
它采用MIT许可证，你可以分叉并移除品牌标识。这更像是请求而非强制要求。
> 盲目复制市场领导者却毫无创新…这策略似乎难以取胜？
或许你并非目标用户——我几个月前就将项目迁移到Codeberg了[0]。坦白说，我对GitHub已不满许久——用户体验虽稳健，但其对开源社区的态度日益恶劣(例如无视明确反对代码用于AI训练的维护者)，更不认同几乎所有开源代码都托管于单一平台/故障点的模式。
长话短说，我并非要求替代平台复制市场领导者的功能布局——我真正需要的是与GitHub功能完全等效、却能规避其弊端的解决方案！其他已迁移至Codeberg的用户也表达了相同观点。
[0] https://codeberg.org/benrutter/wimsey
效仿领导者的界面设计并非明智之选。当知名软件走向僵化时，尝试打造替代方案本就困难重重：若替代品偏离用户习惯过远，必然引发质疑与抱怨。
值得庆幸的是，若你有更优解，完全可以提交PR或自行实现。
机器人验证机制并非Forgejo/Codeberg独有，众多开源项目和组织都采用此法避免机器人流量干扰。我理解你对此的顾虑，但问题远不止Codeberg平台本身。
关于GitHub登录按钮的问题，对社区而言会造成极大困扰：虽然您来自GitHub平台，可能认为自身体验更重要，但本社区由用户驱动而非商业机构，实际开发和使用软件的人群既不需要也不愿优先考虑此类按钮，而是为有需求者保留选择权——这种做法实属难得。若多数用户最终倾向于GitHub登录，可提交问题报告推动相关调整。
你列举的两个问题都属于我所说的“有益问题”——这类服务问题之所以有益，在于它们能立即提醒你：表面之下很可能还潜藏着更多问题。
Codeberg理应兼容无脚本/基础(x)html浏览器，想必也支持IPv6。微软GitHub则在缓慢而彻底地破坏与经典浏览器的兼容性(如今连提交问题都必须使用“whatng”垄断网页引擎)。
(据说Codeberg可能已放弃对无脚本/基础(x)html的兼容性，这将使其变得和微软GitHub或WhatNG GitLab一样毫无特色)
Codeberg团队必须警惕并认清以下现实：当你触及科技巨头的利益时，暗中收受金钱的黑客必将破坏平台。在Codeberg投入的99%时间都将用于维护平台安全与可用性，仅有1%(甚至更少)能用于实际编程。
越来越多用户正离开GitHub。若替代方案中能出现Mercurial支持就更好了…
SourceHut提供Mercurial托管服务：https://hg.sr.ht
我使用SourceHut并庆幸它的存在，但其工作流仍有很大改进空间。
我很好奇，从未用过非Git版本控制工具——Mercurial有哪些优势让你更青睐它？
它更简单直观，操作逻辑更统一，无需繁琐的命令。其设计理念更倾向于保留历史变更记录，而且有TortoiseHg这个优秀的图形化前端工具。
我已迁移完成。
typedload项目最棘手，因需在多版本Python环境下测试，但woodpeckerCI运行正常，迁移后测试仍可执行。
其他项目我没设置CI，本地运行测试太简单了。
有人从Github迁移后使用Codeberg + F-Droid的经验吗？比如能否像在Github那样让F-Droid自动检测Codeberg上的版本发布？
虽非F-Droid，但已看到项目开始支持Codeberg，因其正形成临界效应。
若我接受代码被AI扫描且Grok存在，是否存在非政治原因促使我从Github迁移？
https://sfconservancy.org/GiveUpGitHub/
https://ziglang.org/news/migrating-from-github-to-codeberg/ 这里有更多最新案例。
真希望这类案例能有更完善的整理。
他们最近网站维护不太给力，但这到底有多烦人，就看你自己怎么想了。
上周花了不少时间通过docker和tailscale把Forgejo/Git接入本地NAS。
当Codeberg将一名青少年利用漏洞进行垃圾信息/恶意骚扰[1]的行为(GitHub数年前已解决此类问题[2])扭曲为“极右翼势力发起的仇恨运动”，声称其“危及自由/开源软件项目”，以此吹嘘自身在逆境中[3]的卓越表现时，我对Codeberg仅存的敬意便荡然无存 (顺带对右翼势力大肆抱怨)，却不愿承认本应预见并阻止此事发生。
[1] https://codeberg.org/Codeberg/Community/issues/1786
[2] https://news.ycombinator.com/item?id=31627061
[3] https://blog.codeberg.org/we-stay-strong-against-hate-and-ha…
> 运行CI/CD管道会消耗大量能源。尽管处处标注绿色勾选符号颇具诱惑力，但任务执行需实际支出资金且伴随环境成本。
> 与其他巨型平台不同，我们不鼓励您编写“臃肿”管道并在事后收取费用。我们期望您审慎权衡管道的成本效益，将CI/CD使用量控制在确保项目质量所需的最低限度。
如此矫揉造作
此文似乎出于善意撰写，面向自由开源软件维护者。
如果他们纯粹是想通过刷屏来“恶搞”(这种行为本身就相当无聊)，根本无需在信息中使用种族歧视性辱骂。他们这么做，意图就再明显不过了。
如果一个项目因反对刷屏使用N词而让你失去尊重，这说明的问题更多在于你自身，而非该项目。
恶搞的本质就是尽可能激怒更多人，使用这种词汇恰恰达到了目的。
你真以为一个想尽可能冒犯他人的青少年网络喷子会突然停下来思考：“嘿，我确实超爱惹人生气，但'黑鬼蛋蛋'这个词我不能用”？
> 若因项目反对滥用N词而令你失去敬意，这更暴露了你自身的问题而非项目本身。
他们并非“反对”垃圾信息，而是声称开源软件正面临虚构的极右翼运动威胁。
为何Codeberg要比GitHub承担更高标准？
我曾将仓库迁移至Codeberg，但现已迁回GitHub。
尽管我厌恶GitHub的诸多功能，但Codeberg缺乏足够的吸引力与曝光度。我明白需要有人率先尝试，但作为单人维护者，我需要协作来维持项目运转。
我持续关注着tangled.sh平台的动态，其发展势头显著(基于atproto的Git平台，详见https://tangled.org)