Theo 探索 GitHub 替代品与迁移的社区代价

GitHub 多年来一直是我的代码和社区的家，但服务故障和有关合并异常的报告让我开始考虑替代方案。GitLab、Bitbucket、Gitea、Forgejo 和 Codeberg 给出了不同答案。问题不仅是 Git 仓库可以放在哪里，还包括迁移时会失去或获得什么。

首先明确需求：远程 Git 仓库、拉取请求工作流，以及持续集成和交付。我也看重个人主页、贡献历史和星标等社区功能。可靠性、开源、自托管，以及面向智能体开发的工具也很有吸引力。

GitLab 是很多人首先提到的替代方案。我一直希望有一个开源、可自托管的 GitHub 替代品，但我觉得 GitLab 的用户体验让人受挫。这些是我对特定例子的观察和反应，并非对所有安装方式或版本进行的受控比较。

一个演示中，返回导航时仓库信息消失，页面又分层加载。当网站让我怀疑内容是否完整时，我就会花时间刷新，而不是工作。GitHub 也有加载方面的问题；这个例子没有让我相信 GitLab 会改善体验。

Jason Cox 的例子指出，README 位于项目页面很靠下的位置，发行版链接又与许多视觉权重相同的数字争夺注意力。对于想了解项目或下载发行版的人来说，最有用的信息应该容易找到。

在演示的界面中，如果不记得作者或提交信息，寻找旧提交也显得不便。缓慢滚动历史记录无法很好地替代按日期筛选。本地克隆后可以用其他方式搜索，但托管平台上的浏览体验仍然重要。

在发行版页面上，里程碑完成百分比非常醒目，发布日期却位于更靠下的位置。我想知道发行版何时发布、版本之间改变了什么。这个例子让这些问题变得比我预期的更难回答。

提交页面展示了父提交，但演示中的视图没有给我一个明显的入口，继续前往后续提交。打开包含该提交的分支列表时，界面也出现了卡顿。一个每天都要用的工具，这些细小导航问题会不断累积。

我查看 GitLab 仓库的规模，看到数百万个 Git 对象和庞大的代码库。我的意思是，开放许可证并不意味着任何人都能轻松重新设计复杂成熟的应用。代码行数包含多种文件，也不能直接衡量质量或可维护性。

GitLab 确实提供自托管和企业控制能力，我也听说它的 CI 不错，但这次没有独立测试。总体而言，我仍更喜欢 GitHub 的用户体验。其他团队可能会以不同于我的方式权衡控制权、成本、支持和可靠性。

我习惯按产品代际来思考开发工具。在我的叙述中，Sublime Text、Atom、VS Code 和 Cursor 发展出一类可扩展的编辑器体验，而 Codex app 和我自己的 T3 Code 等面向智能体的界面代表了另一种交互方式。这是整理我个人偏好的方法，并非编辑器历史的严格分代。

类比来看，GitHub、GitLab 和 Bitbucket 主要在已经形成的托管源代码平台这一代产品中竞争。下一代产品可能围绕智能体重新组织工作流，而不是复制同样的界面。录制视频时，这类未来产品仍处于形成阶段。

GitLab 对企业的吸引力包括托管控制权和商业条款，尽管我不喜欢它的界面。与此同时，Bitbucket 突出宣传与 Jira 的集成以及和 GitHub 的成本对比。这可能对已经大量使用 Atlassian 工具的组织有吸引力。

我怀疑主要为了节省每位工程师每月一小笔费用而选择开发平台是否值得。Atlassian 展示的比较也取决于它纳入了哪些 GitHub 安全和支持附加项。应比较自己组织实际需要的功能、用量和支持，而不是把营销倍数当作普遍结论。

Bitbucket 页面还提到了安全功能、支持、服务水平和构建分钟数方案。这些细节可能很重要，尤其对已经使用 Jira 的团队；但包含的分钟数和额外用量需要对照实际套餐与工作负载。我对它的否定态度是个人偏好，不是适用于所有人的建议。

Gitea 是另一个可自托管的代码托管平台。我提到它有免费的 MIT 许可版本和独立商业产品，并指出治理分歧促成了 Forgejo 的出现。存在商业产品，并不意味着开源版本本身已经停止开源。

Forgejo 在一家营利公司接手 Gitea 项目后作为分支出现。Forgejo 称自己是由非营利组织 Codeberg e.V. 支持的自由软件；其项目治理独立于 Codeberg。Codeberg.org 是使用 Forgejo 的托管服务，Forgejo 本身也可以自托管。

我创建了 Codeberg 账户进行试用，原本以为自己会不喜欢。初始加载和 CAPTCHA 体验不太顺畅，但 Forgejo 自己的仓库看起来维护活跃。它比我刚查看的 GitLab 仓库小得多，但规模本身不能证明性能或安全性。

发行版标签页直接提供了我需要的信息，包括日期以及查看相关提交的入口。界面支持主题，我也喜欢发行版 RSS 订阅。它的视觉呈现并不算最漂亮，但重要的开发任务很容易找到。

README 仍然比我希望的位置更靠下。Issue 和拉取请求的界面很熟悉，图片可以嵌入，代码审查界面也能用。在我的测试中，切换 diff 布局会导致整页重新加载，因此体验并非没有瑕疵。

Forgejo 自己的比较强调自由软件治理、测试，以及使用 Forgejo Actions 开发。视频没有独立验证其中提到的某些安全比较。我对它足够认可，因此捐了 1,200 美元，并表示今后每月捐 400 美元。

我想尝试迁移一些项目并测试自己的 CI 设置。Forgejo Actions 支持与 GitHub Actions 相似的工作流，但兼容性未必完全一致；具体 action、runner、密钥和集成均需测试。我使用外部 CI 服务，也需要验证它们能否与新平台配合。

我访问时，Codeberg 状态页显示托管 Actions 出现问题；我很欣赏其公开的状态更新。自行托管 Forgejo 是另一种选择，但运营责任也随之转到自己身上。我看到的状态快照无法证明任何一家供应商总是比另一家更可靠。

我最初误解了自带机器选项：在这里，它涉及 Actions runner，而不是自行托管整个 Codeberg 实例却仍位于其站点上。规划迁移时，这个区别很重要。对于希望拥有开源、可自托管平台的人来说，Forgejo 是一个值得考虑的选项。

我简短提到 SourceHut、CodeCommit、Google Code、SourceForge 和 Phabricator，但没有对它们全部进行同等深入的实测。这次探索后，我更直接的建议是试用 Forgejo 或 Codeberg，判断其工作流是否适合自己。

Pierre 暂停了完整代码托管平台的开发，转而构建底层组件。其中之一是 code.storage，一项面向程序化访问和高吞吐工作流的 Git 基础设施服务。我把它视为未来平台可能采用的构件，而不是已经具备 Issue、拉取请求和社区功能的完整替代品。

Pierre 报告称，它在 30 天内存储了 900 万个仓库，并在连续三小时内达到每分钟 1.5 万个仓库的峰值。我认识该团队，也相信他们的报告，但这属于公司自行报告的工作负载，并非与 GitHub 完整产品之间的独立同条件可靠性比较。

GitHub 的增长指标包含的不只是仓库存储，还有拉取请求和协作服务等。存储后端只能解决整个系统的一部分。我猜测 Git 周边服务是重要的扩展性挑战，但具体故障的原因需要事件证据。

我演示了通过 GitHub 交互式 CLI 从现有本地代码创建仓库。尝试中，Option-Delete 键盘序列反复让提示界面崩溃；流程还会提出许多问题，中间伴随加载停顿。这是一次令人沮丧的实际体验，并不能证明所有 CLI 调用或环境都会如此。

code.storage 的示例通过一次程序调用创建仓库，展示了需要自动创建仓库的软件可以采用的另一种接口。不过，一次 API 调用并不直接等同于交互式设置的每一步。录制时，使用该服务需要获得批准。

一位观众指出，Forgejo 支持通过推送来创建仓库。这项能力取决于实例配置和权限，不能假设所有实例都已启用。但这种低摩擦工作流正是我希望智能体能够使用的。

Pierre 还提供开源 diff 渲染库 @pierre/diffs，T3 Code 使用了它；它也提供文件树渲染库。我喜欢构建可复用组件、让其他开发者自行组合的策略，即使公司完整的 GitHub 替代产品已经暂停。

Graphite 从代码审查切入，提供堆叠变更、导航快捷键、评论和动态流。以我的经验，它让审查更加顺手，但高度依赖 GitHub。我与其创始人是朋友，对它潜力的看法也带有这层关系。

Graphite 增加了仓库镜像，使更多工作可以在自己的基础设施上完成，之后被 Cursor 收购。我猜测合并后的团队未来可能构建截然不同的源代码工作流。我没有关于这些计划的重要内幕信息，因此这只是预测，不是产品公告。

我也在关注前 GitHub CEO Thomas Dohmke 创立的 Entire；我是投资者，这会影响我的视角。它最初的 CLI 希望在代码旁保存智能体会话上下文，目标是保留变更背后的更多决策和迭代过程，而不只是最终 diff。

Zed 也在探索通过 DeltaDB 记录和同步变更，并与 Git 互操作。我不知道未来一代协作工具会继续以 Git 为中心，还是超越 Git。这些项目仍在探索，最终方向尚不确定。

离开 GitHub 最难的部分是社区。个人主页可以把一个人的项目、贡献和讨论联系起来；仓库通常也与 Issue 及维护者集中在一起。这个共同的地点让发现项目和开展协作格外方便。

如果项目分散到各类托管服务和自托管实例，维持这种共同视图就会更难。我担心历史记录碎片化、维护者之间的联系变弱。这是我对迁移可能代价的预测，并不能证明开源社区生活已经结束。

导入工具或聚合器可以恢复部分数据，但我不确信它能重现大家聚在同一个地方的社交体验。我把它比作朋友毕业后各奔东西：他们仍能保持联系，但共同的日常环境改变了。其他人对联邦化和互操作性更乐观，也是合理的。

我仍希望 GitHub 能改善，同时也会支持 Forgejo 和 Codeberg，探索更新的工具。可以针对自己的工作试用替代品、测试迁移细节，并记住代码托管平台也是一个社区。即使新的可能性不断出现，我仍会怀念这个共同的家。