应该将composer.lock致力于版本控制吗？

本文翻译自：Should composer.lock be committed to version control?

I'm a little confused with composer.lock used in an application with a repository. 我对带有存储库的应用程序中使用的composer.lock感到有些困惑。

I saw many people saying that we should not .gitignore composer.lock from the repository. 我看到很多人说我们不应从存储库中.gitignore composer.lock 。

If I update my libraries in my dev environment, I will have a new composer.lock but I will not be able to update them into production, will I ? 如果我在开发环境中更新库，则将拥有一个新的composer.lock但将无法将其更新到生产环境中，对吗？

Won't it generate conflicts on this file ? 它不会在该文件上产生冲突吗？

---

#1楼

参考：https://stackoom.com/question/s72a/应该将composer-lock致力于版本控制吗

---

#2楼

If you update your libs, you want to commit the lockfile too. 如果更新库，则也要提交锁文件。 It basically states that your project is locked to those specific versions of the libs you are using. 它基本上表明您的项目已锁定到您正在使用的那些特定版本的库。

If you commit your changes, and someone pulls your code and updates the dependencies, the lockfile should be unmodified. 如果您提交更改，并且有人拉您的代码并更新了依赖性，则锁定文件应保持不变。 If it is modified, it means that you have a new version of something. 如果它被修改，则意味着您具有某个内容的新版本。

Having it in the repository assures you that each developer is using the same versions. 在存储库中拥有它可以确保每个开发人员都使用相同的版本。

---

#3楼

After doing it both ways for a few projects my stance is that composer.lock should not be committed as part of the project. 在完成几个项目的两种方法后，我的立场是composer.lock不应作为项目的一部分提交。 I know that it is easier to do so but please bear with me while I make a case for this. 我知道这样做比较容易，但是在我为此提出理由时，请多多包涵。

composer.lock is build metadata which is not part of the project. composer.lock是构建元数据，它不是项目的一部分。 The state of dependencies should be controlled through how you're versioning them (either manually or as part of your automated build process) and not arbitrarily by the last developer to update them and commit the lock file. 依赖项的状态应该通过您对它们进行版本控制的方式来控制（手动或作为自动构建过程的一部分），而不是由最后的开发人员随意更新和提交锁定文件。

If you are concerned about your dependencies changing between composer updates then you have a lack of confidence in your versioning scheme. 如果您担心在作曲家更新之间您的依赖关系会发生变化，那么您对版本控制方案将缺乏信心。 Versions (1.0, 1.1, 1.2, etc) should be immutable and you should avoid "dev-" and "X.*" wildcards outside of initial feature development. 版本（1.0、1.1、1.2等）应该是不变的，在初始功能开发之外，应避免使用“ dev-”和“ X. *”通配符。

Committing the lock file is a regression for your dependency management system as the dependency version has now gone back to being implicity defined. 提交锁定文件是您的依赖项管理系统的回归，因为依赖项版本现在已恢复为隐式定义。

Also, your project should never have to be rebuilt or have its dependencies reaquired in each environment, especially prod. 同样，您的项目永远都不必重建，也不必在每种环境中都需要依赖它，尤其是产品。 Your deliverable (tar, zip, phar, a directory, etc) should be immutable and promoted through environments without changing state. 您的可交付成果（tar，zip，phar，目录等）应该是不变的，并且可以在不更改状态的情况下通过环境进行升级。

Edit: I knew going in that this wouldn't be a popular answer, but if you downvote would you be kind enough to provide a reason in the comments that points out the flaw in the answer? 编辑：我知道这不会是一个流行的答案，但是如果您投票否决，您是否会友善地在评论中提供指出原因的理由？ Thanks! 谢谢！

---

#4楼

For applications/projects : Definitely yes. 对于应用程序/项目 ：绝对可以。

The composer documentation states on this (with emphasis): 作曲者文档对此进行了说明（着重说明）：

Commit your application's composer.lock (along with composer.json) into version control. 将应用程序的composer.lock（以及composer.json）提交到版本控制中。

Like @meza said: You should commit the lock file so you and your collaborators are working on the same set of versions and prevent you from sayings like "But it worked on my computer". 就像@meza所说：您应该提交锁定文件，这样您和您的合作者才能使用同一组版本，并避免使用诸如“但是在我的计算机上有效”这样的说法。 ;-) ;-)

For libraries : Probably not. 对于图书馆 ：可能不会。

The composer documentation notes on this matter: 作曲家文档中对此事项进行了说明：

Note: For libraries it is not necessarily recommended to commit the lock file (...) 注意：对于库，不一定建议提交锁定文件（...）

And states here : 并在这里声明 ：

For your library you may commit the composer.lock file if you want to. 对于您的库，您可以根据需要提交composer.lock文件。 This can help your team to always test against the same dependency versions. 这可以帮助您的团队始终针对相同的依赖项版本进行测试。 However, this lock file will not have any effect on other projects that depend on it. 但是，此锁定文件对依赖它的其他项目不会有任何影响。 It only has an effect on the main project. 它仅对主项目有影响。

For libraries I agree with @Josh Johnson's answer. 对于图书馆，我同意@Josh Johnson的回答。

---

#5楼

1. You shouldn't update your dependencies directly on Production. 您不应该直接在Production上更新依赖项。
2. You should version control your composer.lock file. 您应该版本控制您的composer.lock文件。
3. You shouldn't version control your actual dependencies. 您不应该版本控制您的实际依赖关系。

1. You shouldn't update your dependencies directly on Production , because you don't know how this will affect the stability of your code. 1.您不应该直接在Production上更新依赖项 ，因为您不知道这将如何影响代码的稳定性。 There could be bugs introduced with the new dependencies, it might change the way the code behaves affecting your own, it could be incompatible with other dependencies, etc. You should do this in a dev environment, following by proper QA and regression testing, etc. 新的依赖项可能会引入一些错误，它可能会改变代码影响自己的行为方式，可能与其他依赖项不兼容，等等。您应该在开发环境中执行此操作，然后进行适当的QA和回归测试，等等。 。

2. You should version control your composer.lock file , because this stores information about your dependencies and about the dependencies of your dependencies that will allow you to replicate the current state of the code. 2.您应该版本控制您的composer.lock文件 ，因为该文件存储有关您的依赖项以及您的依赖项的依赖项的信息，这些信息将允许您复制代码的当前状态。 This is important, because, all your testing and development has been done against specific code. 这很重要，因为所有测试和开发都是针对特定代码完成的。 Not caring about the actual version of the code that you have is similar to uploading code changes to your application and not testing them. 不在乎所拥有的代码的实际版本类似于将代码更改上传到应用程序而不进行测试。 If you are upgrading your dependencies versions, this should be a willingly act, and you should take the necessary care to make sure everything still works. 如果要升级依赖项版本，这应该是一个自愿的行为，并且应该采取必要的措施以确保一切仍然有效。 Losing one or two hours of up time reverting to a previous release version might cost you a lot of money. 失去一两个小时的正常运行时间来恢复到以前的版本可能会花费您很多钱。

One of the arguments that you will see about not needing the composer.lock is that you can set the exact version that you need in your composer.json file, and that in this way, every time someone runs composer install , it will install them the same code. 关于不需要composer.lock的参数之一是，您可以在composer.json文件中设置所需的确切版本，这样，每当有人运行composer install ，它将安装它们。相同的代码。 This is not true, because, your dependencies have their own dependencies, and their configuration might be specified in a format that it allows updates to subversions, or maybe even entire versions. 这是不正确的，因为您的依赖项具有自己的依赖项，并且它们的配置可能以允许更新子版本甚至整个版本的格式指定。

This means that even when you specify that you want Laravel 4.1.31 in your composer.json , Laravel in its composer.json file might have its own dependencies required as Symfony event-dispatcher: 2.*. 这意味着，即使您在composer.json中指定要使用Laravel 4.1.31，Laravel在composer.json文件中也可能具有其自己的依赖关系，即Symfony event-dispatcher：2. *。 With this kind of config, you could end up with Laravel 4.1.31 with Symfony event-dispatcher 2.4.1, and someone else on your team could have Laravel 4.1.31 with event-dispatcher 2.6.5, it would all depend on when was the last time you ran the composer install. 通过这种配置，您最终可能会获得带有Symfony事件调度程序2.4.1的Laravel 4.1.31，而您团队中的其他人可能会有带有事件调度程序2.6.5的Laravel 4.1.31，这都取决于何时是您最后一次运行composer安装。

So, having your composer.lock file in the version system will store the exact version of this sub-dependencies, so, when you and your teammate does a composer install (this is the way that you will install your dependencies based on a composer.lock ) you both will get the same versions. 因此，在版本系统中拥有composer.lock文件将存储此子依赖项的确切版本，因此，当您和您的队友进行composer安装时（这是您将基于composer安装依赖项的方式。锁定 ），您将获得相同的版本。

What if you wanna update? 如果您想更新怎么办？ Then in your dev environment run: composer update , this will generate a new composer.lock file (if there is something new) and after you test it, and QA test and regression test it and stuff. 然后在您的开发环境中运行： composer update ，这将生成一个新的composer.lock文件（如果有新内容），并在对其进行测试，QA测试和回归测试之后对其进行填充。 You can push it for everyone else to download the new composer.lock , since its safe to upgrade. 您可以将其推送给其他人，以下载新的composer.lock ，因为它可以安全升级。

3. You shouldn't version control your actual dependencies , because it makes no sense. 3.您不应该对实际的依赖项进行版本控制 ，因为这没有任何意义。 With the composer.lock you can install the exact version of the dependencies and you wouldn't need to commit them. 使用composer.lock，您可以安装依赖项的确切版本，而无需提交它们。 Why would you add to your repo 10000 files of dependencies, when you are not supposed to be updating them. 当不应该更新依赖时，为什么要将10000个依赖文件添加到仓库中。 If you require to change one of this, you should fork it and make your changes there. 如果您需要更改其中之一，则应将其派生并在此处进行更改。 And if you are worried about having to fetch the actual dependencies each time of a build or release, composer has different ways to alleviate this issue, cache, zip files, etc. 而且，如果您担心每次构建或发行版本时都必须获取实际的依赖关系，则作曲家可以采用不同的方法来缓解此问题，缓存，zip文件等。

---

#6楼

You then commit the composer.json to your project and everyone else on your team can run composer install to install your project dependencies. 然后，您将composer.json提交到您的项目，团队中的其他所有人都可以运行composer install来安装项目依赖项。

The point of the lock file is to record the exact versions that are installed so they can be re-installed. 锁定文件的目的是记录已安装的确切版本，以便可以重新安装它们。 This means that if you have a version spec of 1.* and your co-worker runs composer update which installs 1.2.4, and then commits the composer.lock file, when you composer install, you will also get 1.2.4, even if 1.3.0 has been released. 这意味着，如果您的版本规格为1. *，并且您的同事运行composer update，该更新将安装1.2.4，然后提交composer.lock文件，则当您进行composer安装时，即使安装了1.2.4，如果1.3.0已发布。 This ensures everybody working on the project has the same exact version. 这样可以确保在项目上工作的每个人都具有完全相同的版本。

This means that if anything has been committed since the last time a composer install was done, then, without a lock file, you will get new third-party code being pulled down . 这意味着，如果自从上一次完成作曲家安装以来已提交了任何东西，那么在没有锁定文件的情况下，您将获得新的第三方代码 。

Again, this is a problem if you're concerned about your code breaking. 同样，如果您担心代码中断，这将是一个问题。 And it's one of the reasons why it's important to think about Composer as being centered around the composer.lock file. 这也是为什么将Composer放在composer.lock文件的中心很重要的原因之一。

Source: Composer: It's All About the Lock File . 资料来源： 作曲家：全部与锁定文件有关 。

---

Commit your application's composer.lock (along with composer.json) into version control. 将应用程序的composer.lock（以及composer.json）提交到版本控制中。 This is important because the install command checks if a lock file is present, and if it is, it downloads the versions specified there (regardless of what composer.json says). 这很重要，因为install命令会检查是否存在锁定文件，如果存在，它将下载在那里指定的版本（无论composer.json说什么）。 This means that anyone who sets up the project will download the exact same version of the dependencies. 这意味着设置项目的任何人都将下载完全相同版本的依赖项。 Your CI server, production machines, other developers in your team, everything and everyone runs on the same dependencies, which mitigates the potential for bugs affecting only some parts of the deployments. 您的CI服务器，生产机器，团队中的其他开发人员，所有事物和每个人都在相同的依赖项上运行，从而减少了可能仅影响部署某些部分的错误。 Even if you develop alone, in six months when reinstalling the project you can feel confident the dependencies installed are still working even if your dependencies released many new versions since then. 即使您是一个人开发，在重新安装项目的六个月中，即使自从那时以来您的依赖项发布了许多新版本，您也可以确信所安装的依赖项仍然有效。

Source: Composer - Basic Usage . 资料来源： 作曲家-基本用法 。