核心手段是通过 composer.json 配置 "git-options": ["--depth=1", "--no-single-branch"] 实现浅克隆，避免下载冗余历史，显著节省带宽与时间；其他 Git 全局配置对此无效。
composer install 和 composer update 默认会从 Git 克隆仓库（尤其是私有包或 vcs 类型的 repository），但 Git 克隆默认不启用深度压缩，导致重复下载大量历史对象，浪费带宽和时间。解决办法不是在 Composer 层配置，而是在 Git 本身启用 core.compression 和更关键的 fetch.fsckObjects 配合策略 —— 但真正起效、可稳定节省流量的是强制 Git 使用 --depth=1 克隆，而这必须通过 Composer 的 git-options 配置项控制。
为什么 git clone --depth=1 是核心手段
Composer 在拉取 VCS 包时底层调用 git clone，完整克隆（尤其含大量 tag/branch 的仓库）常达几十 MB；而 --depth=1 只取最新 commit，体积通常压到 1/5 以内。这不是“可选优化”，而是私有包频繁部署场景下的事实标准。
- 仅靠
git config --global core.compression 9对已克隆仓库有效，但 Composer 每次都可能新建临时工作区，该设置不生效 -
fetch.fsckObjects = true会校验对象完整性，反而增加 CPU 开销，不省流量 - Composer 不读取
~/.gitconfig中的clone.defaultRemoteName等非安全相关设置
在 composer.json 中配置 git-options
这是唯一可靠、项目级生效的方式。在根 composer.json 的 config 节点下添加：
openclaw-gitcode-pr-monitor
下载
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
{
"config": {
"git-options": ["--depth=1", "--no-single-branch"]
}
}
说明：
-
--depth=1强制浅克隆，跳过全部历史提交 -
--no-single-branch避免只拉当前 branch 导致后续composer update切换版本失败（例如切到不同 tag 时 Git 报 “remote ref not found”） - 该配置对所有
vcs类型 repository 生效（git,hg,perforce不适用） - 若项目依赖多个私有 Git 包，此配置一次写入，全局覆盖
注意：某些场景下 --depth=1 会失败
浅克隆虽快，但破坏了 Git 完整性语义。以下情况会直接报错：
- 包中
composer.json声明了"version"字段且值为dev-*<code> 形式，但实际 tag 未被拉取（<code>--depth=1默认不 fetch tag）→ 解决：加--tags，但会增大体积；更稳做法是改用dist方式发布 - CI 环境执行
composer update --lock时，若 lock 文件记录了某 commit hash，而该 hash 不在浅克隆范围内 → 必须配合"preferred-install": "dist"或改用artifact仓库 - 使用
pathrepository 类型时，该配置完全忽略（不走 Git）
真正省流量的关键不在压缩级别，而在拒绝下载不需要的历史。只要项目不依赖 Git 历史操作（如 git log 分析、changelog 自动生成），--depth=1 就是最小侵入、最高收益的选择。别碰 core.compression，它解决不了 Composer 场景下的流量问题。
