我的公司有一个API，使用git和composer来管理它的依赖关系。主项目有大约50个依赖项，它们都属于公司。其中一些有定期的代码更改，而另一些则几个月不更新。
在这一刻作曲家。主项目中的Json所有依赖项都指向dev-dev，但我们希望dev用于开发目的，master用于生产环境。
这意味着作曲家。Json应该包含针对开发环境的dev-dev，而针对产品环境的dev-master。我们考虑使用两个composer (composer.dev.json和composer.prod.json)，当更新依赖项时，使用以下命令:
COMPOSER=composer.dev.json composer update
这样我们就可以根据环境使用它们。我们不喜欢这种方法的地方是依赖项必须在两个composer中复制，或者换句话说，当开发者在composer.dev.json中包含一个依赖项时，他们必须记住也将它添加到composer.prod.json中。这让我们避免使用这种方法，因为我们希望这个过程更加自动化，并避免当开发人员忘记在其他编写器文件中包含依赖项时出现的问题。
考虑到生产部署，管理这种具有如此多依赖关系的应用程序的最佳方法是什么?
如果composer包含一个参数来设置分支为下载，那将是完美的，就像这样:
composer update --branch=dev-dev #Development environment
composer update --branch=dev-master #Production environment
是的，我知道这不是它应该如何工作，但会解决我们的问题:)
这里的任何想法都将非常感激!
问题是什么导致了这里。如果dev/prod并行轨道是领先的，你就不能跳过它们。有了它，你的问题陈述也就清楚了:
我们不喜欢这种方法的地方是依赖必须在两个composer中复制，或者换句话说，当开发者在composer.dev.json中包含一个依赖时，他们必须记住将它也添加到composer.prod.json中。这让我们避免使用这种方法，因为我们希望这个过程更加自动化，并避免当开发人员忘记在其他编写器文件中包含依赖项时出现的问题。
Composer文件是只包含的文件JSON文本。这不是魔法，虽然文本差异可能不是最好的实用方法，但在PHP商店中，编写一个简单的PHP脚本来比较这两个文件的相关部分应该是很容易的。
一个简单的make clean all应该立即显示任何缺失的部分，而你自然只编辑一个文件。或者换句话说:把这个问题委托给你的构建管理器，定义依赖关系和目标，然后就完成它。
使用构建自动化从需要的地方开始。识别痛点可以帮助你找出它在哪里。
这也适用于您的替代方案。如果作曲家有这个分支功能呢?请再说一遍?你需要创建两个JSON文本文件这是相同的但在composer.json#/require下的一些非常具体的地方你交换总是相同的子字符串?也许我没有完全理解你的问题，但恕我直言，没有必要为此修补composer:
make COMPOSER_BRANCH=devmake COMPOSER_BRANCH=master
一个好的构建管理器带有参数化，可以在命令行上处理它们(在你的情况下甚至可能有一个默认值)，只要创建它。