一、背景

如果去 gitee.com/openharmony 看 OpenHarmony 的代码，会发现首页顶部挂着一条黄色公告：

社区已于 **2025-09-15 整体迁移至 https://gitcode.com/openharmony**，提交代码请移步到 gitcode.com/openharmony。原有 Gitee 社区仍提供镜像服务。

也就是说，OpenHarmony 官方代码托管平台已经正式从 Gitee 搬到了 GitCode，Gitee 只保留镜像。对日常"找代码"的人来说，两个站都能看；但对要拉历史、追 commit、查改名的人来说，用哪个站，结果可能不一样。

本文把新旧两个平台的结构差异、以及仓库层面的迁移对应关系，梳理清楚。

二、新旧平台

维度	Gitee（旧）	GitCode（新）
网址	gitee.com/openharmony	gitcode.com/org/openharmony
定位	已迁移，仅镜像	官方主站
仓库数量	728	807（活跃 672 + 已归档 135）
导航结构	概览 / 仓库 / 任务 / PR / 成员	主页 / 项目 / 集合 / Issues / PR / 看板 / 社区讨论
仓库分类	单一"仓库"	代码仓 / 模型仓 / 数据集仓 / Spaces

几个关键点：

1. "代码仓"就是"仓库"。GitCode 之所以改叫"代码仓"，是因为它新增了"模型仓 / 数据集仓 / Spaces"这些并列类型，为了区分传统 git 仓库才换了个名字。目前模型仓、数据集仓、Spaces 都是 0，所以"代码仓 807"就是 807 个代码仓库，可以直接跟 Gitee 的 728 对比。

2. 仓库数 728 → 807，多了 79 个。这 79 个不是凭空冒出来的——GitCode 把仓库分成了"活跃 672 / 已归档 135"，其中一部分是历史仓、归档仓并入了计数，另一部分是迁移后新增的仓。两个站统计口径不同，不能简单说"突然多了 79 个新仓库"。

3. Gitee 仍提供镜像服务。也就是说，gitee.com/openharmony/xxx 这类链接现在还能访问、不会立刻变死链。但镜像的历史完整性、tag 齐全度不一定跟主站一致。

三、GitCode 新平台多了哪些"模块"？

对比旧 Gitee，GitCode 在组织页上明显升级了结构：

• 项目（807）：即代码仓库，替代原来的"仓库"。
• 集合（Collections）：把仓库按主题/用途归类，方便按场景浏览。
• 看板（Boards）：面向项目/任务的看板式管理，比 Gitee 的"任务"更偏协作。
• Issues / Pull Requests：与传统平台一致，并和 GitCode 的云端 AI 编程（AtomCode）打通。
• 模型仓 / 数据集仓 / Spaces：这是 GitCode 面向 AI 时代新设的三类，OpenHarmony 组织目前尚未启用（均为 0）。

一句话总结：GitCode 不只是"换了个域名"，而是把平台从"纯代码托管"往"代码 + 模型 + 数据集 + 云开发"的方向扩了一级。

四、仓库层面的迁移对应关系（重点）

平台搬家只是表象，真正值得关注的是——很多组件仓库在迁移过程中发生了改名、合并、拆分。通过观察 OpenHarmony 官方 manifest 的历史变更，可以把这些迁移归纳为三类：

1. 改名（rename）

仓库名字变了，代码是同一份。典型例子：

旧仓库	新仓库
startup_init_lite	startup_init
distributedschedule_samgr_lite	systemabilitymgr_samgr_lite
update_updateservice	update_update_service
drivers_adapter	drivers_hdf_core
multimedia_audio_standard	multimedia_audio_framework
windowmanager	window_window_manager

这类迁移的本质是改名，代码内容前后对应，只是路径/URL 变了。

2. 合并（merge）

多个仓库并入一个。例如 Hisilicon 的 SoC 与 Board 相关仓库，历史上经历了拆分再合并的反复。

3. 拆分（split）

一个仓库被拆到多个目标仓库。典型是 device_hisilicon_hi3516dv300——它的 init 配置、updater、HAL、SDK 等部分，分别落到了 device_board_hisilicon、device_soc_hisilicon 等不同仓库，而不是简单一对一改名。

为什么拆分最麻烦？因为**"一个旧仓库 → 多个新仓库"不满足一一对应**，如果只靠"改名规则"自动套，很容易定位错。做源码追溯时，拆分关系最好单独人工核验。

五、对实际工作有什么影响？

1. 找最新代码 → 去 GitCode。Gitee 是镜像，可能滞后或缺少部分 tag。
2. 追历史 / 查 commit / 确认"这段代码现在去哪了" → 建议用 GitCode 完整克隆。镜像站做部分克隆时，git log -S（pickaxe 搜索）可能搜不全，容易误判"代码不见了"。
3. 旧链接不要慌。gitee.com/openharmony/... 的链接仍可用，但当证据引用时，建议统一成 gitcode.com/openharmony/...，避免读者点开看到"已迁移"横幅产生疑问。

六、小结

• OpenHarmony 已于 2025-09-15 从 Gitee 整体迁移到 GitCode，Gitee 保留镜像。
• 平台层面：仓库数 728 → 807，GitCode 新增"集合 / 看板 / 模型仓 / 数据集仓 / Spaces"等模块。
• 仓库层面：迁移伴随 改名 / 合并 / 拆分 三类变化，其中"拆分"最需谨慎，不能简单一对一映射。
• 实践建议：找代码、追历史一律以 GitCode 为准，Gitee 当镜像参考。

---

文中迁移公告、平台结构与仓库数量来自 OpenHarmony 官方 Gitee / GitCode 组织页；改名/合并/拆分示例可通过对 OpenHarmony 官方 manifest 历史变更的观察得到。