只用 --depth 1 不够安全，因为它仅限制提交历史深度，不阻止 git 下载所有远程分支引用（refs/remotes/origin/*），导致后续 git fetch 可能意外拉取大量无关分支数据，尤其在 ci 环境中引发性能与稳定性风险。
直接用 git clone --depth 1，但必须配合 --single-branch，否则仍可能拉下其他分支的引用。
为什么只用 --depth 1 不够安全
Git 默认克隆会下载所有远程分支的引用（即 refs/remotes/origin/*），哪怕你只想要 main 分支的最新提交。这些引用本身不占多少空间，但会触发后续 git fetch 或 git pull 时自动同步其他分支——尤其在 CI 环境或脚本里，容易意外拉取完整历史。
常见错误现象：git clone --depth 1 https://xxx/repo.git 后执行 git branch -r，发现依然列出了几十个远程分支；再运行 git fetch，瞬间开始下载大量对象。
-
--depth 1只限制“提交历史深度”，不限制“分支数量” - 如果不加
--single-branch，Git 仍会获取所有分支的 HEAD 引用（哪怕只是空指针） - 某些 Git 服务端（如旧版 GitLab）对 shallow clone 的支持不一致，可能忽略
--depth参数
git clone --depth 1 --single-branch 的实操要点
这条命令才是真正意义上“只拉一个分支、只拉一次提交”的最小化克隆。它能将仓库体积压到原始的 5% 以内，且首次拉取耗时通常控制在 10 秒内（视文件数而定）。
使用场景：
- CI/CD 流水线中构建前拉代码（不需要历史、不需切分支）
- 临时验证某分支最新行为（比如看是否修复了某个 bug）
- 部署服务器上仅需运行时文件，不参与开发
参数差异：
-
--depth 1：本地仓库只有 1 层提交，git log只显示当前提交，git blame失效 -
--single-branch：本地只记录 origin/branch-name这一个远程引用，git branch -r输出仅一行 - 两者组合后，
git status显示为 “initial commit”，git show-branch无输出——这是正常表现，说明确实极简
拉完之后不能干的事，和能干的事
这种克隆方式牺牲了 Git 的部分能力，不是所有操作都支持。容易踩的坑集中在“想当然地当普通仓库用”。
不能做的事：
- 执行
git pull：默认会报错fatal: refusing to merge unrelated histories，因为没有共同祖先 - 切换到其他分支：
git checkout feature/x会失败，提示该分支不存在（本地根本没有它的引用） - 运行
git rebase或git cherry-pick：缺少父提交上下文，操作无法进行
能做的事：
-
git checkout -b my-fix：基于当前提交新建本地分支，可正常 commit -
git push origin my-fix：只要远程允许，可推新分支（注意不是 force push 到已有分支） -
git archive --format=zip HEAD -o latest.zip：打包当前工作区，适合交付或部署
如果连 --depth 1 都卡住，说明问题不在历史而在文件
有些仓库虽然提交少，但单次提交里包含大量二进制文件（如 PSD、视频、LFS 对象）、超多小文件（如 node_modules 打包进 Git）、或巨型静态资源。此时 --depth 1 仍会传输巨量数据。
这时要换思路：
- 优先确认是否真需要全部文件：用
git sparse-checkout init --cone+git sparse-checkout set src/ config/组合，跳过无关目录 - 检查是否有 Git LFS：运行
git lfs ls-files，如有，确保客户端已安装并配置，否则checkout阶段会卡死 - 避免 HTTPS 协议瓶颈：改用 SSH（
git@gitlab.xxx.com:group/repo.git），减少 TLS 握手和认证开销
真正棘手的不是“怎么拉得快”，而是“拉下来之后能不能立刻用”。很多团队把不该进 Git 的东西塞进去，再怎么优化 clone 命令也只是在给错误设计兜底。
