OrderService.java 有 2400 行，四个人同时在改不同方法，一周内产生 9 次合并冲突，其中两次解错导致重复扣款逻辑被覆盖。乍看像缓存或者权限的锅，追下去往往不是。
git log --since='4 weeks ago' --name-only --pretty=format: | sort | uniq -c | sort -rn | head -10 git shortlog -sn --since='4 weeks ago' -- src/main/java/**/OrderService.java
追下去是这么回事：所有订单相关逻辑都堆在一个类里，改动天然重叠。任务拆分按人分，没有按文件或模块分。
碰到「多人并行改同文件」这类问题，我习惯先把当前配置原样备份一份，改坏了立刻换回来，不用现场推。一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。
先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。别只看报错的最后一行，往上看几行，真正的起因通常在上面。
具体做法是，按职责把大类拆成下单 支付 退款三个模块；排期时确认同一文件同一周只有一个负责人；拆分前先做一次纯搬迁提交 不改逻辑；拆完后统计每个文件的月改动人数。
验收就看一点，单个文件的周改动人数不超过 2 人，合并冲突次数降到 2 次以内。