应使用完整40位SHA1哈希值加dev分支名（如dev-main#7f8c...）并配置minimum-stability=dev、--prefer-source，再通过composer.lock的source.reference和git rev-parse验证。

如何用 Composer 安装指定 commit 的 dev-master 版本

直接写 "package-name": "dev-master#abc1234" 就行，但很多人卡在 hash 写错、分支名混淆或未启用 minimum-stability 配置上。

• dev-master 不是稳定版本，必须显式允许非稳定依赖，否则 Composer 会跳过或报错
• commit hash 必须是目标仓库中真实存在的完整 40 位 SHA1（如 7f8c4d9a2e1b3c4d5e6f7a8b9c0d1e2f3a4b5c6d），缩写（如 abc1234）仅在某些 Git 配置下生效，CI 或干净环境里大概率失败
• 如果包的 composer.json 中定义了 default-branch（如 "main"），而你仍写 dev-master，可能拉不到最新代码——因为 master 分支已废弃，实际应改用 dev-main#xxx

为什么 composer require vendor/package:dev-master 失败或装错版本

常见现象是最终安装的仍是旧版、提示 Could not find package，或装上了但 vendor/package/ 下没看到预期的代码变更。根本原因通常是稳定性策略和分支解析逻辑不匹配。

• 默认 minimum-stability 是 stable，dev-master 被直接过滤掉；需在 composer.json 顶层加：

  {"minimum-stability": "dev", "prefer-stable": true}

  或临时运行：

  composer require vendor/package:dev-master --stability=dev

• Composer 会尝试从 dist（zip 包）安装，但 dev 分支通常不生成 dist，得强制走 source：加 --prefer-source 参数，确保检出真实 Git 提交
• 若包启用了 repositories 自定义源，注意优先级：packagist.org 的 dev-master 可能覆盖你本地 path 或 vcs 源里的同名分支

用 # 后缀精确锁定某次提交（推荐做法）

比起模糊的 dev-master，用 commit hash 锁定是唯一可靠方式，尤其用于修复线上问题或验证 PR 补丁。

Software Data Github Interact Developer Helper

帮助用户满足已验证需求：代理用户在Clawhub上对GitHub式工作流有强烈需求，需要实用帮助修复bug、强化设置。

下载

• 格式严格为："vendor/package": "dev-main#7f8c4d9a2e1b3c4d5e6f7a8b9c0d1e2f3a4b5c6d"（注意不是 dev-main#7f8c4d9）
• hash 必须来自目标分支（如 main）的线性历史；若该提交在 feature 分支上、尚未 merge，Composer 会找不到
• 执行后检查 composer.lock 中对应项的 source 字段，确认 reference 值与你指定的一致，且 type 是 git
• 升级时 Composer 不会自动跳到新 commit——这是优点，也是缺点：你得手动改 version 字符串并重装

安装后如何验证是否真用上了目标 commit

别只信 composer show 输出的 version 字段，它常显示 dev-main，掩盖真实 commit。

• 进 vendor/vendor-name/package-name/ 目录，运行：

  git rev-parse HEAD

  对比是否与你指定的 hash 一致
• 看 composer.lock 里该包条目下的 source.reference 字段，必须是完整 40 位 hash
• 如果项目用了 composer install --no-dev，而目标包被列为 require-dev，它根本不会被安装——检查依赖声明位置
• 某些私有 GitLab/GitHub 仓库需要配置 auth.json 才能 clone source，否则 fallback 到 dist 失败，导致安装中断

Composer 的 dev 分支安装本质是 Git 操作的封装，所有“奇怪行为”几乎都源于对 Git 分支模型、Composer 稳定性策略或锁文件机制的理解偏差。最稳妥的做法永远是：明确分支名 + 完整 commit hash + --prefer-source + 核查 composer.lock 和实际 git rev-parse 输出。