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

Question

这是我们的情况：

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

以前，每当核心项目发生变化时，我们只需在我们的服务器上运行 composer update ourvendor/ourcorepackage 来为每个项目引入核心变化。然而，最近，当我们尝试在具有 512 MB 内存的 Digital Ocean 暂存环境上运行更新时，composer 似乎遇到了严重的内存问题。见：https://github.com/composer/composer/issues/1898

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

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

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

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

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

但是这个解决方案引发了 2 个问题：

1. 由于我们在同一个项目上与多个开发人员合作，因此在本地拉取更改时，我们有时最终会遇到 composer.lock 文件的合并冲突。
2. 在服务器上运行 git pull 会出现错误：您对以下文件的本地更改将被合并覆盖：composer.lock 请在合并之前提交您的更改或存储它们。

那么我应该在这里做什么？在服务器上拉之前删除 composer.lock 文件？ 我们应该如何处理 composer.lock 文件的合并冲突？

很遗憾，composer update 遇到内存问题，因为这种方法看起来更合乎逻辑。只需更新您想要的软件包，无需使用 composer.lock 文件..

请建议在我们的案例中，正确的 GIT 和 composer 工作流程应该如何以及如何解决上述冲突？

非常感谢您的意见

Answer 1

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

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

没有办法绕过这个内存要求。仅安装了 512 MB RAM 的 Web 服务器可能能够在几乎没有任何并发​​用户的情况下充当临时服务器，但它不应该用于更新 Composer 依赖项。

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

我不怕更新所有内容，因为要么它按预期工作，要么我的测试会很快发现错误。

我确实选择了我谨慎使用的 3rd 方包：

• 他们必须标记他们的版本，最好使用语义版本控制。
• 我不为发布版本使用任何分支（在开发过程中很少有人使用它们是痛苦的）
• 如果他们做出向后不兼容的更改，他们应该发布一个新的主要版本
• 本地开发的包也遵循这些要求

这适用于我们本地 Satis 实例提供的大约 270 个包（可能也是尝试减少内存占用时要考虑的一个因素 - 只有 Composer 已知的包才能最终进入内存：比较 packageagist 上可能提供的一万个包.org 包含 270 个本地软件包）。 270个包中的60个包由20个开发者在本地开发，并随机发布新版本。最近 2 年的更新失败非常罕见，应该像处理其他 bug 一样处理：如果检测到标记的版本不兼容，我们会发布一个 bugfix 版本来还原更改，并用新的主要版本标记原始更改，如果需要进行不兼容的更改。

所以你要求的工作流程大概是这样的：

• 任何时候，任何开发人员都应该能够在他们的本地计算机上运行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 安装