诺基亚近期向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相关会议讨论意见进一步完善与推进。
