对composer.lock文件的Git跟踪

Question

我正在使用，就像我的项目中总是作曲家一样。

与往常一样，我在git中跟踪composer.lock文件。 首先，因为，一位前任领导开发者如此告诉我。其次，因为实际上获得所有相同的依赖关系。并在生产中轻松安装。

无论如何，我正在使用一些库。它需要symfony /过程。 问题是，在生产服务器上，由于PHP版本（5.4.44），我只能有symfony/process的v2.8.6。

但是在大多数开发者中，我们有PHP5.6或PHP7。因此我们可以使用symfony/process v3.0.6（laste stable release）。

所以在composer.json，我把需要的symfony /工艺= 2.8.6

所以我们都有这个版本。这是工作，任何问题。

我还是有一个问题一直困扰着我。 以某种方式，我会将版本> = 2.8.6放入composer.json中，因此对于dev，我们可以使用v3.0.6，并且在生产中使用兼容版本。

但在这种情况下，我们将始终与composer.lock文件（devs和production之间）产生冲突。 所以，我们无法跟踪它了。 但是，我仍然喜欢获得最新的稳定版本。有时候，我们会将生产服务器更新到PHP 5.6。 所以，使用symfony/process到最新的稳定版本。

所以在这种情况下，我应该停止跟踪composer.lock？ 因为我们可以获得最新版本，并且更容易迁移到PHP5.6吗？

或者，这是跟踪composer.lock文件更好的主意。

谢谢

Answer 1

使用两个分支，一个用于开发，另一个用于生产或与自己composer.lock释放。保持从开发到生产的连续合并，每天或每几个小时或任何其他适当的时间间隔。从dev分支出来并将.lock修改为2.8.6。后来从开发合并到生产将不会引起冲突。开发人员不应该从本地开发人员推送到远程生产分支。

如果您认为2个分行不便，您可以将2个锁添加到回购的适当位置。例如，3.x.x是它应该在的位置，2.x.x在另一个文件夹中。在生产环境中，您可以复制2.x.x版本以替换3.x.x.这可以通过预运行脚本或post-checkout钩子来完成。