git clone --depth 1 是最直接高效的只拉最新代码方式，仅下载目标分支顶端一次提交及所涉对象，体积和耗时降至原仓1%–5%，但需配合 -b 指定分支以确保可靠性，且不支持历史操作。
git clone --depth 1 是最直接、最有效的只拉最新代码的方式。它不下载历史提交，只保留工作区文件的完整快照，体积和耗时通常能压到原仓库的 1%–5%。
为什么 --depth 1 能省空间又快
Git 默认会把整个对象数据库（.git/objects/）全量下载，包括所有分支、所有提交、所有树和 blob。而 --depth 1 只取目标分支 tip 的一次提交及其直接引用的文件对象，跳过所有祖先提交——这意味着：
- 对象数量锐减：以 React 为例，完整克隆有 22 万个对象，
--depth 1后只剩约 2700 个 - 网络传输量下降 90%+，克隆时间从几分钟缩至几秒
- 工作区文件内容完全不变，
yarn install、npm run dev等操作照常运行 - 但
git log只显示一条提交，git checkout <old-commit></old-commit>会失败
--depth 1 必须配合 -b 指定分支才可靠
如果不加 -b，Git 会按远程仓库的 HEAD 引用决定拉哪个分支——而这个 HEAD 可能早已被设为 next 或 dev，不是你想要的 main 或 release/v2.3：
- ✅ 正确：
git clone -b main --depth 1 https://github.com/user/repo.git - ❌ 危险：
git clone --depth 1 https://github.com/user/repo.git（结果不确定） - ⚠️ 远程若没设 HEAD（如裸仓库、CI 构建产出库），命令会直接报错：
remote HEAD refers to nonexistent ref
浅克隆后无法查历史？这是设计，不是 bug
这不是缺陷，而是 Git 明确的语义约束：--depth 1 创建的是一个“无历史”仓库。以下行为都属正常：
-
git log只显示当前 commit -
git blame无法追溯修改来源（除非加--show-stats看当前行作者） -
git merge-base、git rebase等依赖历史的操作会失败 - 某些 IDE 插件（如 VS Code 的 GitLens 历史图）可能功能受限或报错
如果后续需要补全历史，可用 git fetch --unshallow，但会重新下载全部对象——所以别指望“先浅后深”能当通用方案。
CI/CD 中用 --depth 1 要注意触发逻辑
多数 CI 平台（GitHub Actions、GitLab CI）默认已启用浅克隆，但深度不一定为 1：
- GitHub Actions 的
actions/checkout@v4默认fetch-depth: 1，但若 workflow 触发自pull_request事件，它会自动拉 base + head 两个 ref，导致实际 depth > 1 - GitLab CI 的
GIT_DEPTH默认是 50，需显式设为1才真正轻量 - 手动写脚本时，记得加
--no-tags：标签虽小，但大量 tag（尤其带附注的）会额外增加几百个对象
真正最小化的组合是：git clone -b main --single-branch --depth 1 --no-tags <url></url>。多写几个参数，比后期排查慢和大要省心得多。
