相关疑难解决方法(0)

npm 5今天发布,其中一项新功能包括创建package-lock.json文件的确定性安装.

这个文件应该保存在源代码管理中吗？

我假设它类似于,yarn.lock并且composer.lock两者都应该保留在源代码控制中.

composer update和之间有什么区别composer install？

当两个开发人员正在处理具有不同操作系统的项目时,它们Pipfile.lock是不同的(特别是内部部分host-environment-markers).

对于PHP,大多数人建议提交composer.lock文件.

我们是否必须为Python做同样的事情？

这是我们的情况:

我们有3个不同的Laravel项目,所有3个项目都依赖于我们的核心项目.这个Core项目是一个单独的Laravel包,托管在我们的私有仓库上,用作其他项目的依赖项.

之前,只要Core项目中的某些内容发生变化,我们就会在每个项目的服务器上运行一个作曲家更新myvendor/ourcorepackage来引入核心变化.然而,最近当我们尝试在512 MB Ram的数字海洋登台环境中运行更新时,作曲家似乎遇到了严重的内存问题.请参阅:https://github.com/composer/composer/issues/1898

我经常遇到的解决方案是人们说你应该总是在生产服务器上运行composer install.我可以在安全性方面与此相关,因为如果您更新到可能会破坏您的代码的某些第三方软件包的新版本,则可能会很危险.但在我们的例子中,我们只更新自己的核心包,因此我们知道我们正在做什么,但是这个内存问题迫使我们使用composer install方法,因为它对内存要求较低.

基本上这是我们当前的工作流程:

1. 当我们的核心包中的某些内容发生变化时,我们需要在每个项目上运行一个作曲家更新myvendor/ourpackage LOCALLY这将生成一个composer.lock文件

2. 我们在repo中提交composer.lock文件

3. 在每个项目的服务器上,我们运行一个git pull并运行一个composer install.这只会更新我们的核心软件包并且运行速度更快,并且与编译器更新相比没有内存问题

但是,这个解决方案引发了两个问题

1. 由于我们在同一个项目中使用多个开发人员,因此在本地提取更改时,有时会出现composer.lock文件的合并冲突.
2. 在服务器上运行git pull会出错:以下文件的本地更改将被merge覆盖:composer.lock请提交更改或存储它们,然后才能合并.

那我该怎么办呢？在拉动服务器之前删除composer.lock文件？我们应该如何处理composer.lock文件的合并冲突？

令人遗憾的是,作曲家更新会受到内存问题的影响,因为这种方法似乎更合乎逻辑.只需使用composer.lock文件更新所需的包,就不会有任何麻烦.

请告知如何在我们的案例中使用GIT和作曲家的正确工作流程以及如何解决上述冲突？

非常感谢您的投入

在回答如何获取我的私有存储库中包含的包的确切版本时，我声明不应将包composer.lock置于版本控制之下。安装软件包时，根本不会使用该文件。