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></commit-hash>；
• 如果只想要部分文件，可在 A 分支用 git add -p 交互式暂存，再 git commit，避免把调试代码一起提交；
• 不要依赖 git stash pop 后直接 push——它恢复的是“相对于原分支的变更”，不是“B 分支上的合法提交”，容易引发后续 diff 错乱或 CI 失败。

最容易被忽略的一点：stash 恢复失败往往不是命令写错，而是 stash 创建时的基准提交，在目标分支上已经不存在（比如目标分支被 force push 覆盖过）。这时 git stash show -p 查看变更内容，手动复制粘贴反而更快。