应对大型代码托管平台碎片化

# 应对代码托管平台的大分裂 来源：https://www.alexselimov.com/posts/forge_fragmentation/ 浴室瓷砖图案看起来像 10x 开发者的 git 提交历史 我希望有朝一日能成为这样的开发者 似乎有很多人在离开或讨论离开 Github，其中一位非常知名的人物是 Mitchell Hashimoto（https://mitchellh.com/writing/ghostty-leaving-github）。随着个人/公司开始在各个平台（Codeberg、自托管 Forgejo、Gitlab 等）之间分散，分裂似乎不可避免。我认为 Hashimoto 在 Ghostty 项目上的决策可能会为 Github 的衰落定下基调。关于这种情况，我有一些零散的想法： - [跨平台追踪活动](https://www.alexselimov.com/posts/forge_fragmentation/#tracking-activity-across-providers) - [需要某种信任机制来阻止 AI 废料](https://www.alexselimov.com/posts/forge_fragmentation/#some-kind-of-trust-system-is-needed-to-stop-ai-slop) - [现在就把你的用户名锁定好](https://www.alexselimov.com/posts/forge_fragmentation/#get-your-username-locked-in-now) - [自托管是阻止 AI 废料的正确工具吗？](https://www.alexselimov.com/posts/forge_fragmentation/#is-self-hosting-the-right-tool-to-stop-ai-slop?) - [将自托管仓库镜像到 Github 以获得互动](https://www.alexselimov.com/posts/forge_fragmentation/#mirroring-self-hosted-repos-to-github-for-engagement) - [结论](https://www.alexselimov.com/posts/forge_fragmentation/#conclusion) ## 跨平台追踪活动 我希望有朝一日能成为一个 10x 浴室瓷砖开发者，git 贡献热力图是纯色的。我已经遇到一个问题：在追踪我分散在自托管 Forgejo 实例和 Github 上的仓库进度时遇到了麻烦。我是一个简单的人，想看到我的贡献被公开热力图衡量，既为了满足感也为了动力。所以我用 Go 脚本和 Hugo 模块为自己解决了这个问题，你可以用它来创建一个结合多个托管平台数据的 Git 热力图。只需一个 Go 命令就能生成活动文件，再做一些 Hugo 配置更改，以及在你的 Hugo Markdown 中嵌入一个简单的短代码即可。 [[Github 仓库在此]](https://github.com/aselimov/-hugo-unified-git-activity) 这是我的统一 Git 热力图，数据来自我的 [Forgejo](https://forge.alexselimov.com/aselimov) 和 [Github](https://github.com/aselimov) 关于整个情况，我还有一些随机的想法想写下来。 ## 需要某种信任机制来阻止 AI 废料 我认为允许任何有账号的人贡献代码的时代对于开源来说已经结束了。维护者们正被来自未经验证来源的 AI 生成的 PR/Issue 淹没。尽管据说 AI 贡献的质量在提高[1](https://www.alexselimov.com/posts/forge_fragmentation/#fn:1)，但核心的数量问题并没有解决。目前的系统要求维护者去筛选那些可能花费了 0 人力/时间产生的 PR/Issue。即使其中一些是有用/正确的，巨大的数量使得整个系统变得难以处理。你们可能已经知道这一点了。 Hashimoto 针对这个问题提出了一个叫做 [vouch](https://github.com/mitchellh/vouch) 的解决方案，目前正在开发中。它通过一个 Github Actions 工作流，在仓库级别追踪已批准/已屏蔽的贡献者，通过将用户名追加到 `VOUCHED.td` 文件中来实现。该文件的语法如下： ``` # 本项目的已担保贡献者列表。 # # 详情请参见 https://github.com/mitchellh/vouch # # 语法： # - 每行一个用户名（不含 @），按字母顺序排列。 # - 可选平台前缀：平台:用户名（例如 github:user）。 # - 用减号前缀取消担保：-用户名 或 -平台:用户名。 # - 在用户名后可跟空格和可选详情。 aselimov github:aselimov ``` 这是正确方向的一步，但我仍然认为信任机制需要内建到托管平台中。理想情况下，你还需要能够以某种方式启用担保链。即： ``` aselimov 被 user1 在 repo1 上担保 user1 被 user2 在 repo2 上担保 aselimov 间接为 repo2 获得担保 ``` 我认为我们需要一个具有一定进入门槛的网络，以确保贡献者是高质量且有动力的，而不是那些会写攻击文章[2](https://www.alexselimov.com/posts/forge_fragmentation/#fn:2)的机器人。 ## 现在就把你的用户名锁定好 如果我们正在向基于担保的信任模型过渡，你会希望在主流的平台上锁定一致的用户名。这样，如果建立了跨平台的信任链，你因为用户名抢注者冒充你而遇到的问题就会少一些。主要的 Github 替代品似乎是： - Codeberg - Gitlab - Bitbucket 我个人认为 Codeberg/自托管 Forgejo 是最好的选择，但你可能应该在每个平台都注册一个账号以防万一。 自托管 Forgejo 是最大程度上受到保护的信誉系统。大多数情况下[3](https://www.alexselimov.com/posts/forge_fragmentation/#fn:3)，托管者会禁用账号创建，以免被垃圾信息/恶意软件淹没。要获得账号访问权限，你必须联系托管者或已知的管理员来注册。这可能意味着要发邮件、发 LinkedIn 消息、在 X 上发私信等等。我并不完全反对这个概念，如果有一天我启动的项目足够成功而成为 AI 废料洪流的目标。 ## 将自托管仓库镜像到 Github 以获得互动 我目前的工作流程确实涉及将我的所有仓库镜像到 Github，以便实现一定程度的社区互动。主要动机是启用某种 Issue 追踪器，不过接收 PR 也是一个不错的额外好处。将 PR 从 Github 迁移到 Forgejo 需要我手动操作，这起到了一种加固步骤的作用。它确保在我批准 PR 之前，它不会接近我的 CI。如果我的大脑停止工作，我不小心引入了有漏洞的操作[4](https://www.alexselimov.com/posts/forge_fragmentation/#fn:4)，这可以成为一层保护。 ## 结论 - 在你的 Hugo 网站上添加一个 [统一 Git 活动地图](https://github.com/aselimov/-hugo-unified-git-activity)！ - 在所有主要托管平台上建立你的用户名/身份。 - 我不知道接下来事情会如何发展，也不知道 Github 能否复苏。