git clone --depth=1后无法直接checkout其他分支，因为默认只下载当前分支的1个提交且remote.origin.fetch仅配置为该分支，导致其他分支引用缺失；需先执行git config remote.origin.fetch "+refs/heads/:refs/remotes/origin/"，再git fetch origin --depth=1，最后git checkout 。
git clone --depth=1 为什么不能直接 git checkout 其他分支
因为浅克隆默认只获取当前检出分支（通常是 main 或 master）的 1 个提交，且 remote.origin.fetch 配置被设为 +refs/heads/main:refs/remotes/origin/main（或类似），其他分支的远程引用根本没下载。执行 git branch -a 看不到 origin/dev 这类条目，git checkout dev 自然报错：error: pathspec 'dev' did not match any file(s) known to git。
如何安全地在浅克隆后切换到指定分支
别删仓库重 clone，用两步补全所需分支信息：
- 先修正远程分支 fetch 规则：
git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"—— 这步常被跳过，但它是后续能拉到其他分支的前提 - 再拉取目标分支最新提交：
git fetch origin dev --depth=1（或git fetch origin develop） - 最后检出：
git checkout dev（会自动创建本地跟踪分支）
注意：这个操作不会拉完整历史，只拉该分支最新一次提交，仍属“浅”状态，但已足够做编译验证或临时调试。
git fetch --unshallow 是不是万能解药
它能把当前分支恢复成完整历史，但有硬性限制：
- 必须在当前分支上执行，且该分支本身是浅的（
git rev-parse --is-shallow-repository返回true） - 执行后，
git log能看到全部历史，git blame可用，但其他分支依然不可见 —— 因为--unshallow只作用于当前分支的历史链，不自动补全refs/remotes/origin/* - 大型仓库（如 AOSP）可能卡住数分钟甚至失败，Git 会尝试下载所有缺失提交，网络或磁盘压力陡增
CI/CD 中修复浅克隆分支切换的实操要点
Jenkins/GitLab CI 常默认启用浅克隆，但后续需要切分支时容易崩。关键不是“怎么切”，而是“怎么提前预防”：
- 在
checkout步骤显式禁用浅克隆（如 Jenkins 的checkout scm: {..., shallow: false}） - 若必须用浅克隆，Pipeline 中加判断：
git rev-parse --is-shallow-repository为true时，先git config再git fetch origin $TARGET_BRANCH，而非盲目--unshallow - 永远避免在浅克隆仓库里运行
git pull—— 它会触发隐式fetch，但因 fetch refspec 不全，大概率卡在 “Fetching origin” 无响应
真正容易被忽略的点是：浅克隆不是“少下点数据”的优化选项，而是改变了 Git 仓库的元数据结构；一旦用了，所有后续操作都得围绕这个残缺状态设计，而不是指望一条命令就能“变回正常”。
