上游同步与 rebase 纪律

桌面应用上游在动，你的移植分支也在动，两股变化的合并就是日常。这篇讲上游同步与 rebase 的纪律。

▍两种跟进策略
跟随式：定期把上游版本整体纳入（下载新版或拉取里程碑），自己的适配以补丁集重放。适合上游节奏清晰、自己改动集中的工程——Air 系列主流做法。追踪式：建长期分支跟随上游开发线，小步合并。适合需要即时跟进修复的工程，但冲突处理成本常态化。多数移植工程选跟随式：版本对齐的确定性更重要。

▍补丁集的重放
上游新版本到位后：重放补丁集，逐个核对结果。补丁顺利应用不等于语义正确——API 签名变了、行为语义变了，补丁可能应用成功但逻辑失效。重点补丁（平台后端、构建修复）逐个人工复审；重放失败是信号不是障碍：它标出了上游变化与你适配的交点，正好人工介入。每次同步产出记录：上游版本、补丁重放结果（全过、人工处理、放弃及原因）。

▍合并的验证闭环
同步完成必须走完整验证：构建、部署、真机核心路径回归。真实教训：有人把同步当成整理性小改动，同步完没验证就收工，下个会话部署时问题全线爆发——未验证的改动是埋雷。同步日与验证日之间不留空档。

▍冲突多发的治理
同一位置反复冲突，说明适配方式要改：把改动从源码内嵌改成外部配置（能配置就不 patch）、向上游提合并请求（能进上游的不再是本地补丁）、收敛补丁边界（改得越少冲突越少）。补丁数量是健康指标：只增不减说明适配策略有问题。

▍版本策略的沟通
内部记录当前基线（上游哪个版本加补丁集哪个版本）；用户沟通里说明跟版策略（跟随上游稳定版）。长期不跟上游的工程要有明示（维护模式）。

▍验收
同步后的构建与真机回归、补丁清单更新、基线记录更新三件套。

更多真实移植案例，欢迎到 apps 板块翻看 56 篇《鸿蒙PC适配全记录》系列实录。