Git切换分支前需确保工作区干净，否则会因未提交修改被阻止；冲突实际发生在merge阶段而非switch阶段，解决冲突后必须执行git add才能完成合并。
切换分支前先确认工作区干净
Git 不允许你在有未提交修改时直接 git switch 或 git checkout 到另一个分支，尤其当目标分支在相同文件、相同行有不同内容时，会直接报错并阻止切换。这不是 bug，是保护机制。
常见错误现象：error: Your local changes to the following files would be overwritten by checkout
- 用
git status查看哪些文件被修改但没提交 - 如果这些修改还要保留，先
git add+git commit，或用git stash暂存（git stash push -m "wip"） - 如果确定不要，用
git restore <file></file>丢弃单个文件，或git restore .丢弃全部工作区变更
合并分支时冲突发生在 git merge 阶段，不是切换阶段
很多人误以为“切换到 master 再 merge 就能自动解决冲突”，其实冲突只在执行 git merge 时触发。切换本身不产生冲突，merge 才是真正比对差异、尝试自动合并的环节。
典型流程（以把 feature/login 合入 main 为例）：
-
git switch main—— 先切到目标分支（接收方） -
git pull origin main—— 确保本地main是最新，避免后续冲突扩大 -
git merge feature/login—— 此时才可能报 conflict，并停在合并中状态（HEAD is now at ... (no branch, merge)）
此时 git status 会列出 conflicted files，每个文件里都含 和 <code>>>>>>> feature/login 这类标记。
手动编辑冲突文件后必须 git add 才算“解决”
很多人删掉冲突标记、保留想要的代码，就以为完事了，结果 git merge --continue 报错或 git commit 提示 “no changes added to commit”。根本原因是：Git 不靠“有没有标记”判断是否解决，而是看文件是否从 Unmerged 状态变成了 Staged。
- 打开冲突文件，手动删掉
/ <code>=======/>>>>>>及其之间的冗余内容，只留最终要的逻辑 - 保存文件
- 运行
git add <file></file>—— 这一步才是向 Git 声明“这个冲突我搞定了” - 所有冲突文件都
git add完后，再git merge --continue或直接git commit
漏掉 git add 是新手踩得最多、最隐蔽的坑。
用 IDE 或外部工具解决冲突更可靠，但原理不变
IntelliJ IDEA、VS Code、SourceTree 等工具的“Accept Current/Incoming”或三栏对比界面，本质仍是帮你生成一个无冲突的文件内容。它们不会跳过 git add 这步。
- IDEA 中点击
Merge…后，编辑中间栏 → Apply → 它会自动执行git add - VS Code 的 Merge Conflict 扩展，点 “Accept Selection” 后仍需手动
git add，除非你开了自动暂存选项 - 用 Beyond Compare 等外部工具，保存后退出，依然要自己
git add
工具只是省去手工删标记的麻烦，不能绕过 Git 的 staging 机制。只要没 git add，Git 就永远认为冲突还在。
