必须先确保工作区干净，否则 git switch 或 git checkout 会中止并报错；现代 git（2.23+）推荐用 git switch main，语义明确、默认拒绝覆盖未提交修改；若有修改，应 git stash 或提交后再切，切完立即 git pull origin main 同步最新。
直接切到主干分支前，必须确认当前工作区干净，否则 git switch 或 git checkout 会中止并报错。
怎么安全切换到 main 或 master 分支
现代 Git（2.23+）推荐用 git switch，语义明确、拒绝危险操作；老版本或需兼容时仍可用 git checkout。两者本质一致，但行为细节不同：
-
git switch main：默认不覆盖未提交修改，遇到冲突直接报错，不自动合并 -
git checkout main：同样拒绝覆盖，但部分旧版在特定参数下可能表现宽松 - 无论用哪个，只要工作区有未暂存/未提交的变更，都会被拦住，错误信息类似：
error: your local changes to the following files would be overwritten...
工作区有修改时怎么处理才不丢代码
不能直接 -f 强制切，除非你确定那些改动完全不要了。常见且安全的做法是：
-
git stash push -m "wip: sync before main"：把当前所有未提交变更压入栈，干净切换后可用git stash pop恢复 - 如果只改了几行且确定要保留，先
git add再git commit -m "temp"，切完再git reset HEAD~1（慎用） - 绝对避免
git checkout -f main—— 它会静默丢弃所有未暂存修改，不可逆
切过去之后为什么还要 git pull
切换只是让 HEAD 指向本地 main 分支，不代表它最新。远程可能已有别人推送的提交。所以必须紧接着执行：
-
git pull origin main（若远程主干叫main） -
git pull origin master（若远程仍用master） - 漏掉这步就直接 merge 其他分支，很可能引入陈旧基线，导致后续冲突更难解
同步其他分支到主干的典型误操作
很多人以为“切到主干 → merge feature → push”就完了，其实容易卡在两个地方：
- merge 前没
git pull：本地main落后于远程，push 时会被拒绝（non-fast-forward），得先git pull --rebase或强制 push（不推荐） - merge 后没检查是否真同步成功：
git log --oneline -n 5看最新几条提交里有没有 feature 分支的 commit hash，别只信 “Already up to date” - IDEA 里点 “Merge into Current Branch” 时，如果当前是
main，选的是 feature 分支，那才是正向同步；反着选就是把 main 往 feature 上合，方向反了
最常被忽略的一点：远程主干分支名现在基本统一为 main，但很多旧仓库、CI 配置、甚至团队文档还写 master。切之前先跑一遍 git branch -r | grep -E 'origin/(main|master)'，确认真实名称，别硬敲错。
