Composer如何设置默认分支？开发主线与稳定版的切换【教程】-composer-PHP中文网

composer不管理默认分支，仅按约束匹配git分支或tag；必须写dev-main而非main，且常需--stability=dev参数；branch-alias由包作者在extra中声明，仅作别名映射，不改变默认行为。

composer如何设置默认分支？开发主线与稳定版的切换【教程】

Composer 没有“设置默认分支”这个功能，default-branch 配置项根本不存在。 你看到的所谓“设置”，实际是误把 GitHub 的 default_branch API 字段、旧文档错误或第三方工具行为，当成了 Composer 原生能力。真正起作用的是两点：包作者怎么写 branch-alias，以及你 require 时怎么写版本约束。

为什么 `composer require vendor/pkg:main` 总失败？

这不是网络问题，也不是权限问题，而是 Composer 对版本字符串的解析规则导致的：

main、develop、next 这类纯分支名，不是合法的版本约束；Composer 默认只接受语义化版本（如 ^2.0）或带 dev- 前缀的开发分支（如 dev-main）
漏写 dev- 是 90% 相关报错的根源，错误信息通常是 Could not find package 或 Invalid version string "main"
即使写了 dev-main，若项目 minimum-stability 是 stable（默认值），还得加 @dev 后缀或传 --stability=dev 参数，否则仍被过滤

`branch-alias` 是谁该配？怎么配才有效？

branch-alias 是包作者在自己项目的 composer.json 中声明的，目的是告诉 Composer：“我把 dev-main 当作 dev-master 的别名来用”。它不解决“默认拉哪个分支”，只解决“别名映射”问题。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

必须放在 extra 下，不是 config 或根级：

"extra": {
  "branch-alias": {
    "dev-main": "dev-master"
  }
}

这个配置只对当前包生效，下游用户 require 时仍需显式写 dev-main，不会自动 fallback
如果你用的是别人没更新 branch-alias 的老包（比如还硬写 dev-master），你只能手动改自己的 require 约束，或用 repositories 覆盖源

如何安全切换到 `dev-main` 而不污染整个项目？

不要全局改 minimum-stability，那会让所有依赖都可能降级为 dev 版，CI 极易翻车。推荐按包单独授权：

临时试用：composer require vendor/pkg:dev-main@dev —— @dev 是强制声明，绕过当前 minimum-stability 限制
长期依赖：composer require vendor/pkg:dev-main，然后在 composer.json 的 require 下补上对应条目，并确保它没被其他依赖的 minimum-stability 覆盖
更稳妥的写法："vendor/pkg": "dev-main as 2.0.0"，这样 Composer 会把它当作 2.0.0 的开发快照，避免因分支重写导致 composer.lock 锁定失效
上线前务必检查 composer.lock：该包的 version 字段应是类似 "2.5.3" 的稳定格式，而不是 "dev-main" 或带 reference 的 commit hash