我们正在开发一个PHP应用程序及其多个模块依赖项。在开发中，我们想使用dev分支，并在生产中使用标记的版本。
问题在于其中一些模块相互依赖。
在这里处理工作流程的最佳实践是什么？
因为如果在主应用中我们需要开发版本，那么每个人都必须记住在合并到主版本之前对其进行更改。
一种解决方案是使用单独的composer.json文件进行开发，但我认为这对依赖项的依赖项无效。
说明：
开发中的主要应用程序composer.json：
"module_1": "dev-develop",
"module_2": "dev-develop",
在“ module_1” composer.json中：
"module_3": "dev-develop"
在生产主composer.json中：
"module_1": "^1.0.0",
"module_2": "^1.0.0",
在“ module_1” composer.json中：
"module_3": "^1.0.0"
答案 0 :(得分：2)
一个人可以从版本控制中删除composer.json，然后检入两个文件composer.json-template-develop和composer.json-template-main。
请注意，这会泛化到所有配置文件。它使版本控制和部署之间的区别更加明显。 Subversion也推荐使用，引用FAQ:
我的项目中有一个文件，每个开发人员都必须更改，但是我不希望提交这些本地mod。如何使“ svn commit”忽略文件？
答案是：不要将该文件置于版本控制之下。而是将文件模板置于版本控制下，例如“ file.tmpl”。
然后，在初始“ svn签出”之后，让您的用户（或您的构建系统）将模板的常规OS副本复制为正确的文件名，并让用户自定义副本。该文件是未版本控制的，因此它将永远不会提交。并且，如果愿意，可以将文件添加到其父目录的svn：ignore属性，这样它就不会显示为“？”。在“ svn状态”命令中。
答案 1 :(得分：0)
我要挑战前提并说：
不要这样做。
通常，您应该在开发过程中尽量保持与生产版本的距离。这意味着在接近生产的环境中进行测试，使用接近生产数据的数据，并使用将在生产中使用的依赖项版本。任何偏离都会增加遗漏被偏离隐藏的错误的风险。
有时会不可避免地偏离生产（新功能需要新版本的依赖项，由于隐私问题等原因无法使用生产数据等），但这是您应该努力的目标。
也就是说，如果您在开发过程中绝对必须具有不同的依赖项：
因为如果在主应用中我们需要开发版本，那么每个人都必须 记住要在合并后再进行更改。
这似乎表明您在分支上开发了功能，然后合并到母版中。 如果是这种情况，那么最干净的解决方案是在合并之前更改为生产版本。
具有功能分支的全部目的是在合并代码之前对其进行测试。正确测试它需要使用将在主服务器上使用的依赖项。因此，您的合并工作流程应为：
composer.json中没有合并冲突，因为在主服务器上相同）