GIT中的Composer&composer.lock和合并冲突

Question

这是我们的情况:

我们有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和作曲家的正确工作流程以及如何解决上述冲突？

非常感谢您的投入

Answer 1

另一种方法（不做composer update）：

1. 将新的（和删除的）行复制composer.json到一个单独的文本文件中。
2. 使用整个遥控器composer.json和composer.lock文件。
3. 在合并冲突模式期间，请执行以下操作：
   • composer install
   • 对于您在第 1 步中记下的每个新包，运行 composer require vendor/package:version
   • 对于您在第 1 步中记下的每个已删除的包，请运行 composer remove vendor/package
4. 测试！，提交，完成！

此方法将保持来自远程分支（可能master或develop多个分支）的锁，并且仅更新您的新包。

Answer 2

如果开发人员不自己执行此步骤,您如何测试核心更新(或任何其他更新的依赖项)是否会破坏使用它的项目中的内容？

这就是为什么通常的工作流程期望在composer update具有足够RAM的开发机器上运行(即可能超过1GB设置为PHP的内存限制),并且更新应该由开发人员手动触发(并且如果通过持续集成自动触发)构建,内存要求也适用于此机器).

无法满足此内存要求.安装了512 MB RAM的Web服务器可能只能作为临时服务器,几乎没有任何并发​​用户,但不应该用它来更新Composer依赖项.

我个人修复了composer.lock一个非常简单的系统中的合并冲突:删除锁定文件并运行composer update.这将更新所有依赖项以满足版本要求的最新版本,并创建composer.lock在合并期间提交的新工作文件.

我并不害怕可能更新所有内容,因为它可以按预期工作,或者我的测试会很快发现错误.

我确实选择了我使用的第三方包:

• 他们必须标记他们的版本,最好使用语义版本控制.
• 我没有使用任何分支发布版本(在开发期间有人使用它们的罕见情况是痛苦的)
• 如果他们做出向后不兼容的更改,他们应该发布一个新的主要版本
• 本地开发的软件包也遵循这些要求

这与我们当地的Satis实例提供的大约270个软件包一起使用(在尝试减少内存占用时可能也是一个需要考虑的因素 - 只有Composer知道的软件包才能最终存储在内存中:比较packagist.org上可能提供的一万个软件包270个本地包裹).270个包装由270个开发人员在本地开发,并随机发布新版本.过去两年中的更新失败非常罕见,应该像其他错误一样处理:如果检测到标记版本不兼容,我们会发布恢复更改的错误修正版本,并使用新的主要版本标记原始更改,如果需要进行不兼容的更改.

所以你要求的工作流程可能是这样的:

• 任何时候,任何开发人员都应该能够composer update在他的本地计算机上运行.
• 他应该能够发现这是否会破坏他本地机器上的东西.
• 如果没有任何内容被破坏,他会将包括composer.lock文件在内的更改提交给Git
• 登台服务器仅运行composer install并将使用开发人员在其计算机上使用的版本.
• 如果暂存时没有任何内容,那么该版本已准备好用于生产.

将已提交的版本合并到另一台开发人员计算机上可能会显示合并冲突composer.lock.

• 解决所有其他文件的冲突.
• 该composer.lock文件应删除.
• 从这里开始,工作流程如上所述,即:
• 开发人员应该能够composer update在他的本地计算机上运行.
• 他应该能够发现这是否会破坏他本地机器上的东西.
• 如果什么都没有被打破......等等.