有一阵子，我们将本地软件包部署到特定的文件夹packages.stable并将其添加为路径存储库。为了进行测试，每个开发人员都拥有该计算机的副本，并具有一个用于存储个人版本（例如新功能）的类似文件夹packages.mine。与开发人员相比，文件夹packages.mine与packages.stable相比具有更高或更旧的版本，并且缺少某些软件包。由于它是本地存储库，因此在所有composer.json文件中都具有version属性。
这允许composer req my/package1:*@dev使用，而作曲家则采用了最佳选择，如果我的软件包旧或丢失，则选择稳定，如果我的软件包较新，则选择我的。这样，开发人员无需关心所有软件包。
现在，我们想将稳定文件夹包移动到多个VCS。突然，覆盖不再起作用，因为composer up始终忽略本地路径存储库packages.mine，并从VCS中获取“最新提交”。
如果VCS稳定，是否有办法实现前一种方案？还是某些无法预料的行为绑定到本地路径存储库，而这只是偶然的？
答案 0 :(得分：0)
如果使用不同的预发行后缀，这确实是没有问题的。 -dev是一个特殊的保留后缀，dev-master始终指向某个提交，然后将其设置为-dev（dev-master可能指向分支，但仍然指向）。这实际上就是-dev123不是有效的作曲者版本，也是有效的semver的原因。因此，避免-dev意味着忽略最新的提交dev-master。
如果“本地”代码使用的保留后缀不是-dev，则可以使用，例如-alpha。这也使本地代码也可以具有编号后缀，例如-alpha123。添加composer req my/package1:*@alpha会创建所需的状态，在该状态下，本地路径存储库优先于任何VCS版本。
请参见https://getcomposer.org/doc/04-schema.md#minimum-stability