release 分支只修不回合 半年后和主干分叉四十条

线上问题都直接在 release/2.3 上改，主干一直没同步。git log --left-right main...release/2.3 一跑，两边各四十多条，合并时冲突文件二十几个。日志里能对上时间点，这种反而好排。

修复只落在发布分支，主干拿不到，两条线各自演化。时间越长共同祖先越远，冲突面积越大，最后没人敢合。这一点先确认清楚，后面就不用反复试。

git log --left-right --graph --oneline main...release/2.3
git switch main
git cherry-pick -x 3f2a1c9
git merge --no-ff release/2.3

「release 分支分叉」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。

日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。权限不要一口气开到最大，先加到够用再往上试，范围小才好收。

处理上按这个顺序：用 git log --left-right --graph 看清两边各有什么；把 release 上的修复按提交逐条合回主干 别整分支硬合；修完当天就回合 不要攒到发版；主干每周定期 merge 进 release 保持同步；用 tag 标记发布点 分支只做维护。

结果对不对很好判断，两边差异收敛到个位数 合并冲突文件降到两三个。