Composer install 保留 .git 目录需设 "prefer-source": true，支持全局、项目级或单次启用；但仅当包声明有效 "source" 字段时才克隆，否则仍下 dist 包。
composer install 时怎么拿到带 .git 目录的源码
默认情况下 composer install 下载的是压缩包（zip/tar），没有 .git 目录，也就没法看 commit、切分支、提 PR。想保留 Git 信息，必须让 Composer 从 Git 克隆仓库，而不是走 dist 包。
关键在 composer.json 的 "prefer-source": true 配置 —— 它会让所有包（包括依赖树里的间接依赖）都走 git clone，而非下载 dist。
- 全局生效：运行
composer config --global prefer-source true - 项目级生效：在项目根目录执行
composer config prefer-source true，会写入本地composer.json的config段 - 单次生效：
composer install --prefer-source或composer update --prefer-source
注意：--prefer-source 对已安装的包无效，得先 composer install --no-install 清掉 vendor，再重装。
为什么某些包还是没 git 目录？检查 package type 和 source 配置
即使开了 prefer-source，有些包仍不会被 clone，常见原因有两个：
- 包的
composer.json里声明了"type": "metapackage"或"type": "library"但没提供"source"字段 —— Composer 只有在"source"存在且含"url"和"reference"时才支持 clone - 包发布者只配置了
"dist"（比如 GitHub Release zip），压根没填"source"，那 Composer 就没得选，只能下 zip
验证方法：进 vendor/xxx/yyy，执行 git remote -v；如果报 fatal: not a git repository，说明它根本不是 clone 来的。再查该包的 composer show xxx/yyy 输出，看有没有 source: 行。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
dev-main / dev-develop 分支安装后 reference 是什么
用 "dev-main" 这类开发分支名 require 包时，Composer 默认会 clone 当前 main 分支的 HEAD commit，vendor/xxx/yyy/.git/HEAD 指向的是具体 commit hash，不是 symbolic ref（比如不会是 ref: refs/heads/main）。
- 这是故意的：保证可重现性，避免因远程分支移动导致本地行为漂移
- 如果真需要保持分支跟踪（比如持续 sync upstream），得手动进目录执行
git checkout -b dev-main --track origin/main -
composer update时，它会重新 fetch 并硬 reset 到最新 commit，不会自动 merge 或 rebase
所以别指望 dev-main 在 vendor 里能像本地开发那样直接 git pull —— 它本质是个“快照式”克隆。
CI/CD 里要不要开 prefer-source
通常不要。CI 环境追求速度和确定性，prefer-source 会带来三个实际问题：
- Git clone 比下载 zip 慢，尤其包多或网络差时
- 依赖的私有 Git 仓库需配置 SSH key 或 token，CI 配置变复杂
- 某些镜像源（如 packagist.org）不代理 source，可能触发频繁的 GitHub API 限流（403）
如果 CI 里确实要调试源码（比如 dump 函数调用栈），更稳妥的做法是：本地用 --prefer-source 复现，CI 用 composer archive 打包时带上 --format=zip 和 --strip 控制内容，而不是改安装逻辑。
Git 信息不是运行必需的，只是调试辅助——这点容易被忽略，结果为了加个断点，把整个流水线拖慢 30 秒。
