Composer安装fork的GitHub仓库报版本约束不匹配如何解决

按以下顺序逐一排查即可解决问题：

• 首先检查你fork的仓库根目录下的composer.json文件，确认name字段的值严格等于foo/bar。Composer拉取VCS类型源的包时，会以VCS仓库内自带的composer.json声明的包名为准，如果这里的包名和你require的不一致，你配置的VCS源不会被匹配到foo/bar包的拉取逻辑里，Composer会直接走默认的Packagist公共源拉取原仓库的版本，自然只能找到原仓库的dev-main、v0.1.0版本。
• 执行composer clearcache（简写composer cc）清空本地Composer的包元数据缓存。Composer会缓存所有拉取过的包版本、分支信息，如果之前拉取过原仓库的元数据，不会主动重新拉取你新配置的VCS源的分支列表，清缓存是必须的操作。
• 打开你自己的fork仓库页面，确认远程仓库上确实存在develop分支，且分支名没有拼写错误、大小写错误——分支名是完全大小写敏感的，不要出现本地分支推错远程、或者分支名写成dev/develope这类低级错误。
• 如果你的fork仓库是私有仓库，确认当前执行Composer命令的环境有该仓库的拉取权限，权限不足时Composer拉取不到VCS源的分支列表，会静默 fallback 到公共源拉取包版本。
• 执行composer show -a foo/bar 查看当前Composer能识别到的foo/bar所有可用版本，同时可以执行composer why-not foo/bar dev-develop 查看具体的约束冲突细节，排查是否存在全局Composer配置、上层目录composer.json配置了更高优先级的foo/bar源，覆盖了你当前项目里的VCS源配置。
• 清完缓存后不要直接执行composer install，该命令优先读取composer.lock里的锁定版本，不会主动匹配新的分支版本，需要执行composer update foo/bar 触发针对这个包的版本匹配更新。

高频踩坑提示：Composer的repositories配置仅对当前根项目生效，无法递归继承依赖包的repositories配置。如果你是在某个依赖包中配置了这个VCS源，在根项目执行install时是读不到这个配置的，必须把VCS源配置写到最外层根项目的composer.json中才能生效。

内容的提问来源于stack exchange，提问作者JanBoehmer