代码仓库迁移先分清托管方式：Kallithea、Allura、Tuleap、OSDN 与 Codeberg

代码仓库迁移最容易漏掉的不是代码本身，而是围绕仓库积累的权限、问题、Wiki、下载文件和自动化流程。Kallithea、Allura、Tuleap、OSDN 与 Codeberg都能承接开源或开发协作，但它们的托管方式和功能重心不同。迁移前先决定要“自托管控制服务器”，还是要“直接进入一个现成的代码平台”，再安排数据搬迁。

Kallithea适合轻量自托管

Kallithea支持 Mercurial 和 Git，部署轻量，权限管理也较完整，适合小型团队把仓库放在自己的服务器上。它的不足是界面相对陈旧，功能不如大型平台丰富。若现有项目依赖 Git 和 Mercurial、希望保留服务器控制权，Kallithea可以作为简洁的迁移目标；若还需要完整的需求、测试和交付流程，就要继续评估其他平台。

Allura和Tuleap承接更多协作信息

Allura不仅管理代码仓库，还覆盖缺陷、讨论、Wiki和下载统计，适合把开源项目的协作资料一起迁移。它需要一定部署和运维能力，界面也比较传统。Tuleap更偏向从需求到交付的全流程，提供敏捷管理、任务、代码和 CI/CD 集成，适合已经有项目管理制度的团队；学习成本和部分付费能力需要提前确认。

OSDN与Codeberg是不同的托管选择

OSDN支持 Git、SVN、问题跟踪、Wiki和下载统计，适合仍需要 SVN 或希望保留开源项目分发记录的团队，但社区活跃度和界面体验不如主流平台。Codeberg是非营利、社区驱动的 Git 托管平台，提供 CI/CD 和 Pages，强调无广告、无追踪和欧洲数据托管；它更适合接受第三方托管、重视开源社区与隐私的项目。

迁移清单应覆盖五类数据

第一步导出 Git 历史并核对分支、标签和大文件；第二步盘点成员、权限、密钥和 Webhook；第三步决定问题、Wiki、发布包和下载统计是否迁移；第四步改 CI/CD、Pages 和部署脚本；最后为旧地址保留跳转或迁移说明。Kallithea、Allura、Tuleap、OSDN 和 Codeberg的资料侧重点不同，不能用“代码已推送成功”代替完整验收。

如果仓库对外提供下载或文档，迁移还要检查旧链接、发布包、Issue 编号和 RSS 地址。先用一个非核心仓库演练导入，再安排冻结窗口和回滚点，能把权限遗漏、钩子失效和历史链接断裂控制在上线前。

对于仍在使用 SVN、Mercurial 或自定义部署脚本的项目，先记录原平台的版本控制和构建约束，再选择目标平台。迁移报告应保存导入数量、失败列表、权限核对结果和回滚方式，而不是只留下一条“迁移完成”的备注。