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

移动通信标准制定领域最近有一个值得关注的动态：诺基亚向3GPP提交了一份提案，核心建议是将当前工具链中广泛使用的Git rebase操作，全面替换为Git merge操作，用来处理跨版本变更移植。说白了，就是要把不同版本间的代码合并方式彻底换一换。原因其实很直接——Git merge能更清晰地展示每次变更的来源，完整保留历史路径，这恰恰是现在基于rebase的方式在跨版本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相关会议的讨论意见进一步完善和推进。