Git checkout 报“file locked”是操作系统级文件锁所致，常见于IDE或杀毒软件占用文件；“unmerged paths”表明合并/变基未完成；“看不见的修改”多因换行符、权限或临时文件引起；stash pop 冲突需手动处理且不可用 rebase --continue。
git checkout 报错 “file locked by another process”
这不是 Git 自身的冲突，而是操作系统级的文件锁（比如编辑器、IDE、杀毒软件或构建工具正在占用文件），导致 Git 无法安全替换工作目录中的文件。常见于 Windows 上用 VS Code、IntelliJ、PyCharm 或 Visual Studio 打开项目时，它们会独占锁定某些文件（尤其是 .pyc、.dll、.lock、node_modules 下的文件）。
直接关掉 IDE 再试往往就能解决；但更稳妥的做法是先确认谁在锁文件：
- 在 Windows 上运行
handle.exe -a <filename>（需 Sysinternals 工具）或使用资源监视器 → “CPU” 页签 → “关联的句柄”，搜索文件名 - 在 macOS/Linux 上用
lsof +D <path>查看哪些进程打开了该路径下的文件 - 临时关闭杀毒软件实时扫描（尤其 McAfee、360、火绒等常锁住
package-lock.json或build/目录）
git switch 或 git checkout 失败并提示 “unmerged paths”
这说明你正处于一次未完成的合并（git merge）、变基（git rebase）或 cherry-pick 过程中，Git 的索引（index）里还存着冲突标记状态。此时分支切换被禁止，不是因为“有修改”，而是因为 Git 内部状态不干净。
你需要先收尾当前操作：
- 如果卡在
merge：解决完所有冲突后，必须执行git add <file>（或git add .），再git commit - 如果卡在
rebase：解决冲突后，执行git add <file>，然后git rebase --continue（不是commit） - 想放弃当前操作：用
git merge --abort或git rebase --abort，恢复到操作前状态
注意：git status 输出里若出现 “both modified” 且文件名旁标着 “Unmerged”，就属于这类情况——它和普通未提交修改不同，不能靠 git stash 绕过。
切换分支时提示 “Your local changes would be overwritten” 却找不到修改
这种“看不见的修改”通常来自三类干扰：
-
.gitattributes或.git/config中启用了core.autocrlf=true（Windows 默认），导致换行符被自动转换，Git 认为文件内容变了，但git diff看不出差异 - 文件权限变更（如
chmod改了.sh文件的可执行位），在 Linux/macOS 上会触发“修改”状态 - 某些构建工具（Webpack、Gradle）生成的临时文件被 Git 跟踪了，而你本地删掉了它们，Git 认为“缺失”即“修改”
验证方式：git status --ignored 查看是否漏了忽略规则；git diff --no-index /dev/null <file> 可强制对比原始内容；临时关闭换行符转换：git config --unset core.autocrlf（慎用，团队需统一）。
git stash pop 后出现冲突，但没提示“unmerged”
git stash pop 本质是一次 git merge 操作，它把 stash 中暂存的修改“合并”回当前工作区。如果 stash 里的改动与当前分支已有内容重叠，就会产生冲突，但 Git 不会像 git merge 那样明确标记为 “Unmerged paths”，而是静默进入冲突状态——此时 git status 显示 “modified” 或 “unmerged”，取决于冲突严重程度。
关键点在于：stash pop 的冲突必须手动处理，且 git add 后要 git commit（不是 rebase --continue）。如果你误以为这只是“普通修改”，直接 git checkout 切走，stash 的修改会丢失，且冲突残留。
安全做法是：pop 前先 git stash show -p 预览改动范围；pop 后立刻 git status 确认状态；冲突文件里一定存在 <<<<< STASH 和 >>>>> refs/stash 标记，别和 HEAD 冲突混淆。
