Git切换分支后工作区“没变”是因工作区共享机制，未提交修改会保留；stash可安全暂存变更，强制切换（-f）会丢弃未提交内容；真正同步需通过commit+merge/cherry-pick实现。
Git 切换分支后工作区“没变”，不是同步失败，而是 Git 根本没动它——你看到的仍是原来分支上未提交的修改。这不属于“同步问题”，而是 Git 的工作区共享机制导致的必然行为。
为什么切换分支后代码看起来“没更新”
一个本地仓库只有一个工作区和一个暂存区，但有多个分支的提交历史。当你在 feature/login 上改了 src/utils.js 却没 git commit，此时执行 git checkout main：
- 如果
main和feature/login在该文件上没有冲突（即main的对应版本与你修改的原始版本一致），Git 允许切换，src/utils.js的改动会保留在工作区； - 如果
main已经改过同一行，Git 会拒绝切换，并提示Please commit your changes or stash them before you switch branches； - IDEA 或 VS Code 界面显示分支名已切换，但编辑器内容未刷新，本质是它们没触发文件重载，不是 Git 没生效。
git stash 是最安全的临时保存方式
当你需要离开当前分支、又不能提交时，git stash 是唯一推荐的暂存路径。它把工作区 + 暂存区的全部变更打包成快照，然后执行 git reset --hard 回退到最近一次 commit，让工作区恢复“干净”状态。
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
- 执行
git stash save "wip: login form validation"，比默认消息更易识别； - 切到目标分支后，用
git stash pop恢复——注意：它会在当前分支 HEAD 上直接应用变更，若基准不一致可能冲突； - 想避免覆盖风险？先用
git stash apply尝试应用，确认无误再git stash drop； -
git stash list能看到所有 stash，用git stash pop stash@{1}恢复特定条目。
强制切换（git switch -f）会丢弃所有未提交变更
这不是同步，是清空。仅在你明确不需要当前改动时使用：
-
git switch -f main（Git 2.23+ 推荐）或git checkout -f main（旧版兼容）； - 它会丢弃工作区和暂存区中所有未提交内容，包括
git add过但未 commit 的文件； - 未跟踪文件（untracked files），比如新生成的
debug.log，不会被清除，仍留在磁盘上； - IDEA 中右键项目 →
Git → Repository → Reset HEAD… → Hard效果等同，但操作更隐蔽，容易误点。
真正需要“同步”的场景其实是合并或 cherry-pick
如果你本意是把 A 分支上某次未提交的修改“带到” B 分支并提交，stash 只是中转，最终要靠以下方式落地：
- 先在 A 分支
git add+git commit，再切到 B 分支执行git merge A或git cherry-pick <commit-hash>； - 如果只想要部分文件，可在 A 分支用
git add -p交互式暂存，再git commit，避免把调试代码一起提交； - 不要依赖
git stash pop后直接 push——它恢复的是“相对于原分支的变更”，不是“B 分支上的合法提交”，容易引发后续 diff 错乱或 CI 失败。
最容易被忽略的一点：stash 恢复失败往往不是命令写错，而是 stash 创建时的基准提交，在目标分支上已经不存在（比如目标分支被 force push 覆盖过）。这时 git stash show -p 查看变更内容，手动复制粘贴反而更快。
