作曲家＆amp; GIT中的composer.lock和合并冲突

Question

以下是我们的情况：

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

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

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

所以基本上这是我们当前的工作流程：

1. 当我们的核心软件包发生变化时，我们需要运行一个作曲家 更新每个项目的ourvendor / ourpackage LOCALLY这会生成一个 composer.lock文件

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

3. 在每个项目的服务器上，我们运行git pull并运行一个composer 安装。这只会更新我们的核心软件包并且运行速度更快 并且没有与作曲家更新相关的内存问题

然而，这个解决方案提出了两个问题：

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

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

令人遗憾的是，作曲家更新会遇到内存问题，因为这种方法似乎更合乎逻辑。只需使用composer.lock文件更新您想要的包而不用麻烦..

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

非常感谢你的意见

Answer 1

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

这就是为什么通常的工作流期望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。
• 他们应该能够检测到它是否会破坏本地计算机上的内容。
• 如果什么都没有被打破......等等。

Answer 2

另一种方法（不做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 3

有时候composer update可能会破坏事情。 我要做的是。

1. 放弃对composer.lock的所有更改
2. 合并composer.json
3. 运行composer install，以便根据composer.lock安装软件包。
4. 如果您有一个软件包，请运行composer require vendor/package 添加了该软件包；如果已删除，则添加composer remove vendor/package。 如果有多个软件包，它将从composer.json
自动安装