在代码锻造平台上，你需要哪些GitHub功能才能进行迁移？
摘要
Lobsters上的一场讨论探讨了哪些GitHub功能是迁移到不同代码锻造平台的关键障碍，作者正在构建一个名为juju.bi的锻造平台，专注于离线协作、GitHub API兼容性以及基于change-id的功能。
<p>你认为哪些GitHub功能会成为迁移到其他代码锻造平台的障碍，并且你会按什么顺序对它们进行优先级排序？</p>
<p><strong>背景：</strong></p>
<p>我正在埋头构建一个代码锻造平台（<a href="https://juju.bi" rel="ugc">https://juju.bi</a>），它基于三个理念：</p>
<ul>
<li>代码协作部分应支持离线工作</li>
<li>应与GitHub API兼容（类似某些服务被视为S3兼容）</li>
<li>支持基于<code>change-id</code>的功能（例如：Jujutsu的evolog）</li>
</ul>
<p>我已经发布了一个超早期版本，目前正在自用。<a href="https://juju.bi/changelog/2026-07-01-alpha-release" rel="ugc">https://juju.bi/changelog/2026-07-01-alpha-release</a></p>
<p>我目前专注于改善使用私有仓库的小团队的体验。在考虑公共仓库之前，我希望先打磨整体产品。（目前有很多优秀的锻造平台支持公共仓库）。</p>
查看缓存全文
缓存时间: 2026/07/01 12:00
# 在你迁移之前，一个代码托管平台需要具备哪些 GitHub 功能？
来源：https://lobste.rs/s/w01x4p/which_github_features_are_needed_code
你会把哪些 GitHub 功能视为迁移到另一个代码托管平台的障碍，以及你会按什么顺序对它们进行优先级排序？
**背景：**
我正在埋头构建一个代码托管平台（https://juju.bi/），其基于三个理念：
- 代码协作部分应支持离线工作
- 应与 GitHub API 兼容（就像某些服务被视为 S3 兼容一样）
- 支持基于 `change-id` 的功能（例如：Jujutsu 的 evolog）
我发布了一个超级早期的版本，目前正在自用测试：https://juju.bi/changelog/2026-07-01-alpha-release
我目前专注于改善私有仓库小团队的使用体验。在考虑公共仓库之前，我想先把整体产品打磨好。（目前已有许多优秀的公共仓库代码托管平台。）
相似文章
你希望从代码托管平台得到什么？
Lobsters上的一个讨论帖，询问开发者希望在代码托管平台中看到哪些功能，特别是关于版本控制展示和协作模型，并提及了Jujutsu和Git等工具。
为何我要从 GitHub 迁移至 Forgejo
本文探讨了从 GitHub 迁移到自托管的 Forgejo 的决定，主要提及了对数据所有权、可靠性以及 AI 数据收集实践的担忧。文章还介绍了荷兰政府类似的举措，并详细说明了个人 Forgejo 实例的技术部署。
应对大型代码托管平台碎片化
本文探讨了项目离开GitHub导致的代码仓库碎片化问题，介绍了一种跨平台统一git活动热力图的工具，并讨论了抵御AI生成垃圾贡献的信任系统。
Forge
Forge 是一个全新的 CLI 与 Go 库，通过统一接口和自动 forge 检测，一次性打通 GitHub、GitLab、Bitbucket 与 Gitea/Forgejo 的交互。
我们应得的代码锻造平台
本文讨论了对GitHub可靠性日益增长的不满，并提出基于AT协议的去中心化Git锻造平台Tangled，作为一个结合了中心化便利性与用户数据所有权的有前途的替代方案。