诺基亚近期向 3gpp 提交了一项重要提案，建议对 3gpp 当前使用的工具链进行关键优化——将跨版本变更移植所依赖的 git rebase 操作，全面替换为 git merge 操作。此举的核心动因在于：git merge 能更直观地呈现变更来源，并完整保留变更历史路径，从而有效弥补现有 rebase 方式在跨版本 cr 移植过程中追溯性薄弱的问题，更好地支撑 3gpp 在多版本共存、多 cr 并行推进的规范演进场景下的协作需求。
3GPP 是全球移动通信技术标准的核心制定组织，其核心使命是协同全球通信产业链（包括运营商、网络设备商、芯片厂商等），制定统一、开放、互操作的移动通信技术规范（即“标准”），确保不同厂商设备间的兼容与互通。
该提案聚焦于 3GPP TR 21.802 技术报告，服务于 FS_6GSpecs 工作项，旨在构建面向 6G 规范高效、可持续迭代的工程化基础能力，目前已正式进入 3GPP 审批流程。
提案的技术架构围绕 Git 仓库组织方式、版本演进策略及合并执行机制三大维度展开，精准应对多版本并行维护与多 CR 协同开发中的典型管理挑战。在仓库设计层面，明确为每一项技术规范（例如 TS 38.300、TS 38.331）设立专属独立仓库，确保每个变更请求（CR）与其所属规范严格绑定，分支归属清晰无歧义；同时依托 GitLab 的分组管理能力，支持按工作组（WG）或规范系列实施层级化归类，兼顾规范粒度独立性与整体治理效率。
版本号体系亦同步完成标准化定义：新一代规范起始于 0.1.0 预发布版本，经若干轮迭代后达到 1.0.0 稳定预发布状态，待正式批准后升格为首个正式版本（如 21.0.0），后续通过持续合入 CR 进行功能增强与问题修复，依次演进至 21.1.0、21.2.0 等小版本。在分支管理策略上，main 分支将严格对应最新正式发布版本的演进主线，采用 “fast-forward 合并” 模式（仅更新引用指针，不生成新提交节点），从机制上规避合并冲突风险；而每次新版本发布均基于当前最新稳定版创建独立发布分支，发布前以 draft/ 前缀标识，正式发布后则剥离前缀转为纯语义化版本号分支（如 21.0.0），确保整个生命周期轨迹可查、可验。
在变更移植的关键环节，提案重构了运行中 CR（基线 CR）与目标版本之间的同步逻辑。以 Release 19 规范为例，其基线 CR 初始基于 Release 18 的 v18.4.0 版本建立；当 Release 18 后续升级至 v18.5.0、v18.6.0 等新版本时，可通过 Git merge 快速将新增变更整合进 Release 19 的草稿分支，实现跨版本内容同步。针对“当前版本 CR 已修复某缺陷，但新发布 CR 尚未适配该修复”的潜在跨版本冲突情形，提案明确规定：必须优先保障当前版本的修复成果落地，严禁因移植操作导致已有功能退化或回归问题。
此外，提案还展示了典型发布周期内的并行运作模型：以 Rel-21 与 Rel-22 为例，Rel-21 的日常维护工作（如缺陷修复、文档勘误）与 Rel-22 的前瞻性规范开发可同步开展。维护类 CR 经审批后直接合入对应版本分支并打上版本标签；而具备成熟度的工作项分支，则可合并至下一代规范的草稿分支，最终沉淀为正式版本。该模式既保障了既有版本的长期稳定性与持续优化能力，又完全释放了新一代规范的研发节奏与创新空间。
业界普遍认为，若该提案顺利获批，将显著增强 3GPP 规范开发过程的透明度、可审计性与可复现性，尤其契合 6G 技术攻关阶段所面临的多版本演进、多团队协同、高频次迭代等复杂工程挑战，为 3GPP 工具链迈向现代化、工程化、可持续演进提供关键支撑。目前，该提案已被列为议程项 6，后续将依据 3GPP 相关会议讨论意见进一步完善与推进。
