必须用 dev-分支名 语法 + 显式声明 repositories，否则 Composer 默认只查 Packagist；分支名含斜杠需写成 dev-release/2.4.x，CI 需确保仓库可访问且 Satis 已同步元数据。

私有 Composer 包要支持多分支开发和测试，核心不是“能不能”，而是“怎么让 composer require 精准拉到你想要的分支，且不污染生产环境”。直接结论：必须用 dev-分支名 语法 + 显式声明 repositories，否则 Composer 默认只认 Packagist 上的稳定版本或 tag。

为什么 dev-branch-name 会报错 “Could not find a version”

常见现象是执行 composer require vendor/package:dev-feature/login 后报错，但该分支明明存在。根本原因不是分支不存在，而是 Composer 没去你的 Git 仓库查 —— 它默认只查 Packagist。

• 必须在目标项目的 composer.json 中提前声明 repositories，且 type 设为 vcs，url 指向你的私有 Git 地址（如 https://git.yourcompany.com/vendor/package）
• url 必须可被 CI 和本地机器直连；若用 SSH，需预置 ~/.ssh/config 或 GitHub token（HTTP 地址推荐带 ?token=xxx）
• 分支名含斜杠（如 release/2.4.x）时，require 中必须写成 dev-release/2.4.x，不能省略 dev- 前缀
• 如果分支刚推上去，Packagist 私有实例（如 Satis）尚未 rebuild，composer update 仍可能失败——此时要确认 Satis 是否已同步该分支元数据

如何在测试环境临时切分支而不改 composer.json

开发中频繁切换分支做集成测试，手动改 composer.json 太重。推荐两条命令流，不碰配置文件：

Discussion Composer

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

下载

• 安装指定分支：composer require vendor/package:dev-main --with-all-dependencies（--with-all-dependencies 防止依赖冲突）
• 回退到其他分支：composer require vendor/package:dev-staging，Composer 会自动替换 vendor/package 目录并更新 composer.lock
• 注意：每次 require 都会触发 composer update 行为，若只想更新单个包，加 --no-update 再手动 composer update vendor/package
• CI 测试脚本里别用 composer install，而要用 composer update --prefer-dist，确保拉取的是 composer.lock 锁定的分支 HEAD 提交，而非本地缓存

发布前如何验证分支包是否可安装

别等上线才发现 dev-* 包装不上。最简验证法：在空目录下模拟下游项目行为。

• 新建测试目录，运行 composer init 创建最小 composer.json
• 手动添加 repositories 和 require，例如：

  {
    "repositories": [
      {
        "type": "vcs",
        "url": "https://git.yourcompany.com/vendor/package"
      }
    ],
    "require": {
      "vendor/package": "dev-feature/auth"
    }
  }
  

• 执行 composer install -vvv，观察日志里是否出现 Cloning [commit-hash] from [your-url]，而不是 Skipped branch ... no matching package found
• 关键陷阱：如果私有仓库用了子模块或 LFS，composer install 默认不递归 clone，需在 repositories 中加 "options": {"git": {"recursive": true}}

真正容易被忽略的点是：分支名大小写敏感、Git 仓库权限未开放给 CI 服务账号、以及 composer.lock 中记录的是提交哈希而非分支名——这意味着即使分支被 force push，已安装的包也不会自动更新，必须显式 composer update。