Composer支持通过dev-前缀或commit hash安装非稳定版本，需配置minimum-stability为dev，注意缓存、仓库类型及CI环境限制。
直接在 composer.json 中指定 dev 分支或 commit hash
Composer 支持通过版本约束语法安装非稳定分支（如 dev-main、dev-develop）或特定 commit（如 dev-master#abc1234），无需 fork 或手动下载。
关键点是：必须使用 dev- 前缀 + 分支名，或加 # 后接完整 commit hash（40 位或短 hash，但推荐用完整 hash 避免歧义）。
-
"monolog/monolog": "dev-main"→ 安装main分支最新提交 -
"myvendor/mylib": "dev-feature/login#7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b"→ 安装该 commit 对应的代码 - 如果包未声明
minimum-stability，需显式设为"minimum-stability": "dev"，否则 Composer 默认拒绝 dev 版本 - 建议同时加上
"prefer-stable": true，避免意外拉取其他不稳定的依赖
为什么 dev-branch#hash 有时不生效？
常见失效原因是 Composer 缓存了旧的包元数据，或远程仓库未正确暴露该 commit 所属分支。
GitHub操作助手
下载
用大白话操作当前项目的 Git/GitHub——配置 GitHub（装 gh CLI + 登录 + 建仓库）、备份、拉取下载、查询历史、回滚代码、管理分支。当用户用日常语言表达 git 意图时触发（例如"git备份一下""git下载项目""git拉下来""git看看我改了啥""git回退到上一个版本""git新建个分支搞新功能""git合并到主分支""git
- 执行
composer clear-cache清除本地缓存 - 确认目标 commit 确实存在于该分支的历史中（用
git ls-remote origin branch-name检查） - 某些私有 Git 仓库（如自建 Gitea/GitLab）需配置
repositories指向正确的 VCS 类型，例如：{ "type": "vcs", "url": "https://git.example.com/myvendor/mylib.git" } - 若用 SSH URL（如
git@git.example.com:myvendor/mylib.git），确保本地 SSH key 已配置且能正常 clone
用 require 命令行快速安装 dev 版本
不用手动改 composer.json，适合临时验证或 CI 场景。
composer require myvendor/mylib:dev-maincomposer require myvendor/mylib:dev-develop#abcd1234- 加
--no-update可只写入composer.json，不立即安装（适合批量修改后统一处理） - 加
--update-with-dependencies可强制更新该包及其子依赖（慎用，可能破坏兼容性）
commit hash 安装的实际限制
虽然语法支持 dev-master#hash，但 Composer 实际行为取决于 Packagist 或你配置的仓库是否索引了该 commit。
- Packagist 不会为每个 commit 创建独立版本；它只同步分支 HEAD 和 tag。所以
dev-main#hash能工作，是因为 Composer 会克隆整个仓库并检出该 commit —— 这要求包源支持 Git 协议访问 - 私有包必须配置为
vcs类型仓库，HTTP(S) ZIP 包源不支持 commit 检出 - CI 环境中若禁用 Git 克隆（如只下载 ZIP），
#hash会失败并回退到分支 HEAD，这点容易被忽略
