我们的情况是这样的:
We have 3 different Laravel projects and all 3 projects rely on our Core project. This Core project is a separate Laravel package hosted on our private repo and is used as a dependency for other projects.
以前，每当核心项目发生变化时，我们都会在服务器上运行composer update ourvendor/ourcorepackage， for each 项目引入核心变化.然而，直到最近，当我们试图在带有512 MB Ram的数字海洋登台环境上运行更新时，composer似乎遇到了严重的内存问题.见:https://github.com/composer/composer/issues/1898
The solution I always come across is people saying that you should always run composer install on your production servers. I can relate to that in terms of security because it can be dangerous if you update to a new version of some 3rd party package that can possibly break your code. But in our case we only update our own core package so we know what we're doing but this memory issue forces us to use the composer install method because it is less memory demanding.
基本上这就是我们目前的工作流程:
- 当我们的核心包中发生变化时，我们需要运行编写器 在本地更新每个项目的供应商/软件包这将生成 Composer.lock文件
We commit the composer.lock file in our repo
在每个项目的服务器上，我们运行git pull和composer
然而，这种解决方案提出了两个问题:
- Since we're working with multiple devs on the same project we sometimes end up having merge conflicts for the composer.lock file when pulling in the changes locally.
- 在服务器上运行git pull会出现错误:对以下文件的本地更改将被merge:composer覆盖.锁
So what am I supposed to do here? Before the pull on the server remove the composer.lock file? How should we handle the merge conflicts for the composer.lock file?
遗憾的是，Composer更新受到内存问题的困扰，因为该方法似乎更符合逻辑.只需更新您想要的软件包，就可以轻松地使用Composer.lock文件.
请建议在我们的情况下，使用GIT和Composer的正确工作流程应该是怎样的，以及如何解决上面的冲突？
非常感谢您的意见