git switch -c 本地分支 origin/远程分支比 checkout 更稳，因其语义明确、不误触发文件恢复、不默认进入分离 HEAD 状态，且自动建立跟踪关系并拒绝覆盖未提交修改。
直接切回远程分支起点，用 git switch -c 或 git checkout -b 搭配 origin/xxx 即可，不需要先 fetch —— 但前提是本地没改过该分支的 HEAD，否则会出错。
git switch -c 本地分支 origin/远程分支 为什么比 checkout 更稳
Git 2.23+ 默认启用 git switch，它专为分支切换设计，语义清晰、容错更强。当你执行：
git switch -c feat-login origin/feat-login
Git 会自动做三件事：创建本地 feat-login 分支、让它跟踪 origin/feat-login、把工作区更新为远程该分支最新提交的状态。
相比 git checkout -b，switch 不会误触发“检出文件”逻辑（比如你手误少打一个 -b，checkout 可能直接覆盖当前文件）；也不默认进入分离 HEAD 状态。
- 如果远程分支已存在且你本地没有同名分支，
switch会成功建立跟踪 - 如果本地已有
feat-login分支，但它的起点不是origin/feat-login，命令会报错并提示你加-C强制重置 - 它不修改暂存区或工作区以外的内容，不会意外丢弃你刚
git add的文件
checkout -b origin/xxx 失败的常见原因和修复
很多人执行 git checkout -b dev origin/dev 报错 “fatal: Cannot update paths and switch to branch 'dev' at the same time”，本质是 Git 检测到当前工作区或暂存区有未提交变更，拒绝覆盖。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
这不是网络问题，也不是远程不存在，而是本地状态冲突。解决方式分情况：
- 如果你只是想丢弃本地所有未提交修改，运行
git restore .（Git ≥2.23）或git checkout -- .（旧版） - 如果只想清空暂存区但保留工作区，用
git restore --staged .或git reset - 如果这些修改有用，先
git stash存起来，切完分支再git stash pop - 确认远程分支真实存在：
git ls-remote --heads origin dev—— 如果没输出，说明远程根本没有dev分支
切过去之后，如何确保本地分支真的“回到起点”
所谓“回到远程分支起点”，是指本地分支的 HEAD 和 origin/xxx 完全一致，而不是只复制了文件内容。验证方法很简单：
git status
如果输出是 “Your branch is up to date with 'origin/dev'.”，就对了。
如果显示 “Your branch is behind 'origin/dev' by X commits.”，说明你本地分支虽然名字一样，但指向的提交落后于远程——这通常是因为你之前手动 reset 过、或者用 git checkout <commit> 进入过分离 HEAD 状态后又创建了同名分支。
- 强制同步：用
git reset --hard origin/dev（仅限本地无重要未推送提交时） - 安全同步：用
git merge origin/dev或git rebase origin/dev，但会引入新提交 - 最稳妥重建：删掉本地分支
git branch -D dev，再重新git switch -c dev origin/dev
真正容易被忽略的是：远程分支起点 ≠ 你上次 fetch 时的起点。Git 不会自动刷新 origin/xxx 的指针，除非你显式 git fetch 或 git pull。所以每次切换前，建议先 git fetch origin，尤其在多人协作中，别人可能已经 push 了新提交。
