3GPP 对象链改革提案出炉：诺基亚提议用 Git merge 替代 Git rebase，晋升 6G 规范迭代透明度

诺基亚近日向 3GPP 提交了一份提案，建议对 3GPP 对象链进行关键进级 —— 将当前用于跨版本变革移植的 Git rebase 操作调换为 Git merge，修改原因是 Git merge 比拟 Git rebase，能更透明地展示变革来源，且变革轨迹可追踪，解决当前 rebase 方法在跨版本移植 CR 时的追溯性不足问题，更适配 3GPP 规范迭代中多版本、多 CR 并行的场景。

该提案针对 3GPP TR 21.802 规范，适配 FS_6GSpecs 工作项，旨在为 6G 技巧规范的高效迭代奠定基本，今朝已进入审批阶段。

此次提案的核心设计环绕 Git 仓库构造、版本治理与归并机制展开，针对性解决多版本并行、多 CR（变革请求）协同场景下的治理痛点。在仓库架构上，提案明白为每个技巧规范（如 TS 38.300、TS 38.331）零丁创建自力仓库，确保变革请求与具体规范精准绑定，分支归属无歧义；同时借助 Gitlab 的分组功能，支撑按工作组（WG）或规范系列进行层级化治理，兼顾自力性与分类效力。

版本号演进规矩也迎来清楚定义：新一代规范将从 0.1.0 预宣布版本起步，经多次迭代至 1.0.0 稳定预宣布版，审批经由过程后进级为正式版本（如 21.0.0），后续经由过程归并变革请求持续迭代至 21.1.0、21.2.0 等版本。分支治理方面，main分支将专注追踪最新正式版本的动态，采取 “fast-forward 归并” 模式（仅移动分支指针，不创建新提交），从根源上避免归并冲突；新宣布分支基于当前版本最新版创建，宣布前以 “draft” 为前缀标识，正式宣布后生成纯版本号分支，确保迭代轨迹清楚可溯。

在变革移植关键流程上，提案优化了运行 CR（基线 CR）与当前版本的同步机制。以 Release 19 规范为例，其运行 CR 初始基于 Release 18 v18.4.0 创建，当 Release 18 迭代至 v18.5.0、v18.6.0 等新版本时，经由过程 Git merge 可将新增变革快速归并至 Release 19 的草稿分支，实现跨版本同步。针对可能出现的 “当前版本 CR 修复 bug 与新宣布 CR 未适配” 的跨版本冲突，提案明白需优先保障当前版本修复成果，避免变革移植过程中出现功能回退。

3GPP 是全球移动通信技巧标准制订机构，其核心本能机能是调和全球通信行业（运营商、设备商、芯片厂商等），制订同一的移动通信技巧规范（即 “标准”），确保不合厂商的产品互联互通。

值得留意的是，提案还展示了宣布周期内的并行治理模式：以 Rel-21 与 Rel-22 为例，Rel-21 的规范保护工作与 Rel-22 的规范性开辟可同步推动，保护类 CR 经审批后归并至对应版本分支并打标签，工作项分支成熟后则归并至新一代规范的草稿分支，最终迭代为正式版本。这种设计既保障了 legacy 版本的持续优化，又不影响新一代规范的开辟进度。

业内认为，若该提案获得经由过程，将明显晋升 3GPP 规范迭代的透明度与可追踪性，尤其适配 6G 技巧研发中多版本、多团队协同的复杂场景，为 3GPP 对象链的现代化进级供给重要支撑。今朝，该提案已作为议程项 6 提交审批，后续将根据 3GPP 会议评论辩论成果进一步完美。