同一状态的多个副本必然漂移

更新于 2026-09-22

同一状态的多个副本必然漂移

# 同一状态的多个副本必然漂移

同一份状态存在多处副本时（本地 / 远端、工作区 / HEAD、worker / 主仓、两个数据源）， 漂移是默认状态，不是异常。 任何一处的绿灯只对那一份成立。判据一句话：先把副本对齐到同一条标识（commit / 版本 / 游标 / id），再谈「行不行」。

出处	绿灯 / 状态	它实际对应的副本	症状
合并绿灯要对应当前HEAD	PR 上 CI 全绿、显示「可合并」	旧提交（本地又提交了但未 push）	合进去的不是刚改好的版本
开PR前先确认基线的远端状态	本地分支看起来只领先几个提交	远端主线落后很多	PR 带进一长串无关历史
交付前先同步主干	本地验证通过	已漂移的主干	交付后冲突 / 回归
多源更新按维度取真源	「取更新的那个源」	两个源各自在部分维度更新	拿到的是一份混合、互不同步的产物

旁证：远端主线可能与本地主线无共同祖先 —— 副本之间的差异可以大到连共同祖先都没有，此时「对比一下」这个动作本身就不成立。

副本漂移不需要任何错误操作就会发生。 只要有两处可以独立写入，它们就会分叉；所以「我本地是好的」在结构上就不能推出「交付出去是好的」。
对齐的载体必须是「同一条标识」：commit SHA、版本号、游标、记录 id —— 而不是「看起来一样」「刚才跑过」「名字相同」。这也是对照两端要用同一条标识的同一形状。
可迁移的动作：看到任何绿灯 / 状态页 / 「已验证」时，先问三句 —— 「它对应的是哪一条标识？」「我手上这份是同一条吗？」「这中间有没有人又写过？」 三句都对齐，绿灯才有意义。
顺带推论：把副本数量压到最少，比把校验做得更勤更划算。 能收敛到单一真源的，就不要维护两份再同步。

更新时序要由本地最新状态决定 —— 那条处理时间维度的乱序（谁最后返回）；本条处理空间维度的分叉（谁和谁不是同一份）。两者都是「权威性没有显式记录」的后果。
真源要按维度显式指定 —— 本条的上游：真源定不下来，副本必然互相冒充。
存量不会自动跟上新逻辑 —— 同族：只改了其中一份，另一份不会自己跟上。

单看每一页，都是某次 git / 数据源的具体事故。并排之后才看得出它们共享同一个结构：状态被复制，而权威性没有被复制。