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

Composer & composer.lock in GIT and merge conflicts

提问by cenob8

Here's our situation :

这是我们的情况：

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.

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

Before, whenever something would change in the Core project we woud just run a composer update ourvendor/ourcorepackage on our servers for each project to pull in the core changes. However as of lately composer seems to suffer from serious memory issues when we try to run the update on our Digital Ocean staging environment with 512 MB Ram. See : https://github.com/composer/composer/issues/1898

以前，每当 Core 项目发生变化时，我们只需在我们的服务器上运行一个 composer update ourvendor/ourcorepackage 来为每个项目引入核心更改。然而，最近 Composer 似乎遇到了严重的内存问题，当我们尝试使用 512 MB Ram 在我们的 Digital Ocean 登台环境上运行更新时。见：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 install。我可以在安全性方面与此相关，因为如果您更新到可能会破坏您的代码的某些 3rd 方软件包的新版本，这可能会很危险。但是在我们的例子中，我们只更新我们自己的核心包，所以我们知道我们在做什么，但是这个内存问题迫使我们使用 composer install 方法，因为它对内存的要求较低。

So basically this is our current workflow :

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

1. When something changes in our core package we need to run a composer update ourvendor/ourpackage on each project LOCALLY This generates a composer.lock file

2. We commit the composer.lock file in our repo

3. On the servers for each project we run a git pull and run a composer install. This will only update our core package and runs much faster and has no memory issues vs composer update

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

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

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

However this solution raises 2 issues :

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

1. 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.
2. Running a git pull on the server gives an error : Your local changes to the following files would be overwritten by merge: composer.lock Please, commit your changes or stash them before you can merge.

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

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.lock 文件？我们应该如何处理 composer.lock 文件的合并冲突？

It's a shame that composer update suffers from memory issues because that method seems much more logical. Just update the package you want and no hassle with the composer.lock file..

遗憾的是 composer update 遭受内存问题，因为这种方法似乎更合乎逻辑。只需更新您想要的包，而无需使用 composer.lock 文件。

Please advice how a correct workflow with GIT and composer should be in our case and how to solve the conflicts above ?

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

Many thanks for your input

非常感谢您的意见

回答by Sven

How can you test that a core update (or any other dependency that gets updated) doesn't break things in the projects using it if the developer don't do this step themselves?

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

That's why the usual workflow is expecting the composer updatebeing run on a development machine having enough RAM (i.e. probably more than 1GB set as memory limit for PHP), and the update should be triggered manually by the developer (and if triggered automatically by a continuous integration build, the memory requirements apply to this machine as well).

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

There is no way around this memory requirement. A web server with only 512 MB RAM installed might be able to function as a staging server with barely any concurrent users present, but it shouldn't be used to update the Composer dependencies.

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

Personally I fix the merge conflicts in the composer.lockwith a very easy system: Delete the lock file and run composer update. This will update all dependencies to the latest versions that satisfy the version requirements, and create a new working composer.lockfile that get's committed during the merge.

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

I am not afraid to potentially update everything, because either it works as expected, or my tests will catch errors quickly.

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

I do select the 3rd party packages I use carefully:

我确实选择了我谨慎使用的第 3 方软件包：

• they have to tag their versions, preferably using semantic versioning.
• I do not use any branches for release versions (the rare occasions that someone used them during development were painful)
• they should ship a new major version if they make backwards incompatible changes
• the locally developed packages also follow these requirements

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

This works with around 270 packages served by our local Satis instance (probably also a factor to consider when trying to reduce memory footprint - only the packages known to Composer can end up in memory: Compare the ten thousand packages potentially available on packagist.org with 270 local packages). 60 packages of the 270 are locally developed by 20 developers, and randomly releasing new versions. The update failures in the last 2 years are very rare, and should be handled like other bugs: If a tagged version is detected to be incompatible, we release a bugfix release reverting the change, and tag the original change with a new major release, if the incompatible change is necessary.

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

So the workflow you ask for is probably like this:

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

• Anytime, any developer should be able to run composer updateon their local machine.
• They should be able to detect if this breaks things on their local machine.
• If nothing is broken, they commit the changes including the composer.lockfile to Git
• The staging server only runs composer installand will use exactly the versions that the developer used on his machine.
• If nothing is broken on staging, that version is ready to be used on production.

• 任何时候，任何开发人员都应该能够composer update在他们的本地机器上运行。
• 他们应该能够检测到这是否会破坏他们本地机器上的东西。
• 如果没有任何问题，他们会将包括composer.lock文件在内的更改提交到 Git
• 临时服务器只运行，composer install并且将使用开发人员在他的机器上使用的版本。
• 如果暂存时没有任何问题，则该版本已准备好用于生产。

Merging an already committed version on another developers machine will likely show merge conflicts with composer.lock.

在另一台开发人员机器上合并已经提交的版本可能会显示与composer.lock.

• Resolve conflicts on all other files.
• The composer.lockfile should be deleted.
• From here, the workflow is like above, i.e.:
• The developer should be able to run composer updateon his local machine.
• They should be able to detect if this breaks things on his local machine.
• If nothing is broken... and so on.

• 解决所有其他文件上的冲突。
• composer.lock应该删除该文件。
• 从这里开始，工作流程如上，即：
• 开发人员应该能够composer update在他的本地机器上运行。
• 他们应该能够检测到这是否会破坏他本地机器上的东西。
• 如果没有损坏……等等。

回答by Xover

Another approach (without doing composer update):

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

1. Copy your new (and deleted) lines from composer.jsoninto a separate text file.
2. Use entire remote composer.jsonand composer.lockfiles.
3. During merge conflict mode do:
   • composer install
   • For every new package your wrote down in step 1 run composer require vendor/package:version
   • For every removed package your wrote down in step 1 run composer remove vendor/package
4. Testing!, Commiting, done!

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

This method will keep locks from remote branch (maybe masteror developbranches), and only updates your new packages.

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