把修复提交摘到发布分支时出现冲突，解决后提交内容与预期不一致。日志里能对上时间点，这种反而好排。
目标分支的上下文与源分支不同，同一段代码已被改动，直接套用会冲突。这一点先确认清楚，后面就不用反复试。
git cherry-pick 3f2a1b9 git status git add src/fix.py git cherry-pick --continue
「git cherry-pick 冲突」确认了原因之后，改动尽量只碰那一处，顺手改的东西后面最容易出问题。能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。
报错里带路径的，先去看那个路径在不在、权限对不对。同一份配置存在多处的，先确认改的是被加载的那一份。
新版本先放一台机器上跑一天再全量，问题一般在这段时间暴露。备份不是备了就行，恢复一次才算数，很多备份文件打开才发现是空的。
处理上按这个顺序：先看清冲突块的两边来源；保留业务需要的版本并手动验证；继续完成拣选。
结果对不对很好判断，拣选完成，修复逻辑在目标分支生效，相关用例通过。