諾基亞近日向 3GPP 提交了一份提案，建議對 3GPP 工具鏈進行關鍵升級 —— 將當前用於跨版本變更移植的 Git rebase 操作替換為 Git merge，修改原因是 Git merge 相比 Git rebase，能更透明地展示變更來源，且變更軌跡可追蹤，解決當前 rebase 方式在跨版本移植 CR 時的追溯性不足問題，更適配 3GPP 規範迭代中多版本、多 CR 並行的場景。

3GPP 是全球移動通信技術標準制定機構，其核心職能是協調全球通信行業（運營商、設備商、芯片廠商等），制定統一的移動通信技術規範（即 “標準”），確保不同廠商的產品互聯互通。

該提案針對 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 未適配” 的跨版本衝突，提案明確需優先保障當前版本修復成果，避免變更移植過程中出現功能回退。

值得注意的是，提案還展示了發佈週期內的並行管理模式：以 Rel-21 與 Rel-22 為例，Rel-21 的規範維護工作與 Rel-22 的規範性開發可同步推進，維護類 CR 經審批後合併至對應版本分支並打標籤，工作項分支成熟後則合併至新一代規範的草稿分支，最終迭代為正式版本。這種設計既保障了 legacy 版本的持續優化，又不影響新一代規範的開發進度。

業內認為，若該提案獲得通過，將顯著提升 3GPP 規範迭代的透明度與可追蹤性，尤其適配 6G 技術研發中多版本、多團隊協同的複雜場景，為 3GPP 工具鏈的現代化升級提供重要支撐。目前，該提案已作為議程項 6 提交審批，後續將根據 3GPP 會議討論結果進一步完善。