git clone -b 指定分支时本地无代码，是因为未正确执行一次性全新克隆；正确做法是直接 git clone -b branch_name url，而非在已有仓库中重复运行 clone 命令。
git clone -b 拉指定分支时，本地没代码？
不是命令失败，是你理解错了执行前提：git clone -b <branch> <url> 是「一次性动作」，它不依赖已有本地仓库。如果你先 git clone <url> 进了默认分支（比如 main），再在项目目录里补跑 git clone -b dev ...，那第二个命令会报错或新建另一个目录——它根本不会作用于当前工作区。
正确做法只有两种：
- 全新拉取：直接
git clone -b dev https://example.com/repo.git，本地立刻得到dev分支，HEAD 指向它，且自动设置上游为origin/dev - 已有仓库：别用
clone，改用git fetch+git checkout或git switch
常见错误现象：git clone -b dev .（点号）或在已存在 repo 目录下重复 clone，结果是「Permission denied」或「destination path already exists」。
git checkout -b local-branch origin/remote-branch 的本质
这条命令不是“拉代码”，而是“创建本地分支并让它跟踪远程分支”。它要求你已经运行过 git fetch（或 git pull），否则 origin/remote-branch 根本不存在于本地数据库里。
执行后发生三件事：
- 本地新建一个叫
local-branch的分支，起点是origin/remote-branch当前指向的提交 - HEAD 切换到
local-branch - 自动设置
upstream：运行git branch -vv会看到local-branch abc123 [origin/remote-branch]
注意：origin/remote-branch 是只读的远程跟踪分支，不能直接 git checkout origin/remote-branch —— 那会进入「分离 HEAD」状态，后续提交无法被分支引用。
git switch -c 和 git checkout -b 的区别在哪
git switch 是 Git 2.23+ 引入的专用分支切换命令，语义更清晰，也更安全。它和 git checkout -b 功能等价，但默认行为更克制：
对 GitHub Actions 工作流 YAML 文件进行 lint 与验证，检查常见错误、安全隐患、已废弃的操作以及最佳实践。适用于要求进行代码检查、验证等场景。
-
git switch -c feat/login origin/feat/login：必须显式指定起点，不会意外基于当前分支创建 -
git checkout -b feat/login：如果没给起点，默认基于当前 HEAD 创建，容易误操作 -
git switch不支持文件恢复（那是git restore的事），避免checkout一词的歧义
如果你用的是 Git 2.23 或更新版本，优先写 git switch -c；老版本就只能用 git checkout -b。两者生成的本地分支、追踪关系、推送行为完全一致。
为什么 git pull origin branch-name 失败却提示“not tracking”
因为 git pull 本质是 git fetch + git merge，但它只对「已建立追踪关系」的本地分支生效。如果你只是 git fetch origin 拿到了 origin/dev，但没运行 git checkout -b dev origin/dev 或 git switch -c dev origin/dev，那么本地根本没有 dev 分支，git pull origin dev 就会报错：
fatal: 'dev' does not appear to be a git repository
或者更隐蔽的：There is no tracking information for the current branch —— 这说明你当前在某个分支（比如 main），但它没设 upstream，而你又没指定要 pull 哪个远程分支。
解决路径唯一：先确保本地有对应分支，并设好 upstream。最简一步到位写法是：
git switch -c dev --track origin/dev
之后 git pull 就能直接用了。
