git clone --depth 1适用于ci/cd构建、代码审查、临时验证等短生命周期场景，仅下载最新提交，节省时间与空间；但不支持查看历史、切换分支或旧提交，且需配合--single-branch -b 使用。
浅克隆（git clone --depth）只适合“不改历史、不切分支、不查旧提交”的一次性读取场景；它不是开发用的替代方案，而是构建、审查、CI 等短生命周期任务的加速手段。
什么时候该用 git clone --depth 1
核心判断标准：本地仓库用完即删，且不需要执行 git log --all、git blame、git bisect 或切换到其他分支。
- CI/CD 流水线中构建最新代码：例如
git clone --depth 1 --branch main https://github.com/org/repo.git，拉完立刻npm install && npm run build，构建完目录直接被清理 - 代码审查前快速检出某分支最新状态：只需看当前 diff 和文件结构，不追溯修改来源
- 本地临时验证某个 PR 的最新提交是否通过编译，不打算做任何本地提交或 rebase
- Homebrew 更新时拉取
homebrew-core：官方默认就是--depth=1，因为只关心 latest formula 文件内容
--depth 和 --single-branch 必须一起用
单独加 --depth 1 仍会下载所有分支的远程引用（refs/remotes/origin/*），只是每个分支只保留 1 个提交。这既浪费带宽，又容易在后续 git checkout 时触发隐式 fetch，导致卡住或失败。
正确写法必须显式限定分支：
git clone --depth 1 -b main --single-branch https://github.com/user/repo.git
-
-b main指定起始检出分支（影响HEAD指向） -
--single-branch确保只拉取该分支的提交链，不拉其他origin/develop等引用 - 二者缺一不可；漏掉
--single-branch会导致远程引用残留，后续git fetch行为异常
浅克隆后哪些 Git 操作会失败或受限
不是所有命令都报错，但很多行为会偏离预期，尤其在脚本自动化中容易静默出问题：
-
git log --oneline -20：只能看到 1 条（或--depth指定的条数），无法翻页 -
git checkout abc1234（某旧 commit hash）：报错fatal: reference is not a tree，因为该 commit 根本没下载 -
git merge origin/develop：如果develop分支未被克隆，会提示unknown branch；即使已存在，也可能因缺少共同祖先而拒绝合并 -
git pull：默认等价于git fetch && git merge，但浅克隆的 fetch 可能失败或只拉新提交不补历史，导致 merge 冲突难以 resolve -
git subtree push或git submodule update：子模块初始化可能失败，因父仓库缺少足够提交上下文来校验 submodule commit 是否可达
想“先快后全”？别依赖 git fetch --unshallow
很多人以为浅克隆后可以随时转成完整克隆，实际中这个操作代价高、风险大：
-
git fetch --unshallow本质是重跑一次完整历史 fetch，网络中断就前功尽弃，且无法断点续传 - 部分托管平台（如 GitHub、GitLab）对浅克隆 remote 的 promisor 机制支持有限，
--unshallow可能直接报错error: Server does not allow request for unshallowed fetch - 即使成功，本地对象数据库会突然膨胀数倍，磁盘 I/O 压力大，CI 节点可能因此超时或 OOM
- 真正需要完整历史的场景，一开始就不该用浅克隆——直接上
git clone --filter=blob:none更稳妥
浅克隆真正的边界很清晰：它不是“轻量版完整克隆”，而是一种有明确生命周期约束的临时数据快照。一旦你开始怀疑“会不会以后要用历史”，那就该换方案了。
