文件被回退先分清是工具还是并发会话

更新于 2026-09-21

**看到「文件被 linter 大幅回退了」，第一步不是去查 linter 配置，而是先确认这个工具到底有没有写文件的能力。** 如果 lint 脚本只是 `eslint .`（没有 `--fix`），那它**不可能改文件**，这条线索当场排除 —— 剩下的嫌疑只有「另一个 session 同时在写同一批文件」。

分诊顺序

  1. 核对被怀疑的工具是否有写能力。 看脚本本身（有没有 --fix、格式化、checkout、restore）。没有写能力 → 直接排除，不要在这条线上耗时间。
  2. 看工作区还剩哪些改动、哪些文件同时带着多个来源的 diff。 若一个文件里既有本轮改动、又有别人先前的差异，它就是并发冲突高风险文件。
  3. 确认是否有并行 session 在改同一批文件（同一 worktree 内的多 session 与跨 worktree 是两种不同情形）。

修复原则：按 hunk 合并，不整文件回滚

  • 先暂停所有在改同一批文件的 session，否则边修边被覆盖。
  • 找到另一个 session 的目标改动来源，先保存它的 diff/patch。
  • 不要 reset 整个文件 —— 会把别人的改动一起删掉。正确做法是「按 hunks 合并」：保留别人的改动，再把自己的 patch 重新套上。
  • 只碰自己这轮真正改过的文件，不是自己改的文件不动。
  • 验证只跑 lint / build，不跑任何带 --fix、格式化、checkout、restore 的命令 —— 那会再制造一次「文件被改回去」。

可迁移的判断

归因「是谁改的」之前，先确认被怀疑的对象是否具备「改」的能力。 不具备写能力的工具/命令可以直接从嫌疑名单里划掉；剩下能改文件的只有「并发写者」和「你自己」。这条和「先分清平台错误还是应用错误」是同一个动作：先用排除法把不可能的分支砍掉，再在剩余分支里找根因。

相关