Git报错“Your local changes would be overwritten”是安全保护机制，非bug；它因工作区修改与目标分支HEAD内容冲突而中止切换，解决路径只有暂存（git stash）、提交或丢弃，强制切换（git checkout -f）仅适用于确认无价值的修改。
git checkout 报 “Your local changes would be overwritten” 怎么办
这是 Git 在阻止你丢代码，不是 bug，是保护机制。它检测到：你改了某些文件 + 这些文件在目标分支的 HEAD 版本里内容不同 → 切过去会覆盖你的修改，所以中止操作。
别急着点「强制切换」，先看清楚哪些文件被拦住了：
- 运行
git status，确认当前有哪些未提交改动 - 运行
git diff --name-only HEAD origin/dev/xilong.zhao/sdk_update_Release_S2.4.0K01（把分支名替换成你要切的目标分支），看哪些文件在两个分支底版本间确实存在差异 - 重点检查报错里列出的文件：它们是你改过的，且目标分支的同名文件和你当前分支的“基线”不一致
这时候你只有三个明确路径：暂存、丢弃、或先提交——没有第四个“安全绕过”选项。
用 git stash 暂存修改再切换最稳妥
git stash 是专为这种场景设计的，它把工作区和暂存区的改动打包藏起来，不提交、不污染历史，切完还能原样拿回来。
操作步骤很直接：
- 执行
git stash push -m "wip: sdk update prep"（加-m方便后续识别） - 再执行
git checkout dev/xilong.zhao/sdk_update_Release_S2.4.0K01 - 切过去后，如果想恢复刚才的改动，就运行
git stash pop
注意：git stash pop 可能触发合并冲突（比如你 stash 的改动和目标分支新内容重叠），这时 Git 会像 merge 一样标出 <<<<<< HEAD 区块，需手动编辑解决；git stash apply 则只应用不删除 stash 记录，适合想多试几次的情况。
什么时候可以直接 git checkout -f 强制切换
git checkout -f 会无条件丢弃所有未提交的本地修改，等价于先执行 git checkout -- . 再切换。它只适合以下情况：
- 你 100% 确认这些改动毫无价值（比如临时 debug 打的日志、生成的 mock 文件）
- 你刚 clone 项目，只改了几行测试代码，还没进任何逻辑
- 你在 CI 脚本里做自动化构建，环境本就不该保留脏状态
千万别在改了一半功能、没 commit 也没 stash 的时候用 -f。Git 不会二次确认，执行完就没了，连 git reflog 都救不回工作区内容。
为什么有时改了很多却没提示？关键看基线是否一致
很多人以为“改得多就一定弹窗”，其实完全相反：弹窗与否只取决于一个判断——你改的文件，在当前分支和目标分支的 HEAD 提交里，原始内容是否相同。
举例说明：
- 你在
main上改了utils.js，而dev/xilong.zhao/...分支的utils.js和main的上一次提交一模一样 → 切过去不弹窗，你的修改直接带过去 - 你在
main新增了config.local.yml（未 add 未 commit），目标分支压根没这个文件 → 同样不弹窗，文件保留在工作区 - 你已经
git add并git commit了所有改动 → 切任何分支都不会触发这个提示
真正容易被忽略的是：Git 做比较时用的是「目标分支的 HEAD 快照」，不是远程最新、也不是你本地暂存区——所以即使你刚 git fetch 过，只要目标分支本地没更新到最新提交，判断依据仍是旧快照。
