不应该直接在生产端更新依赖项。 你应该版本控制你的作曲家。锁文件。 您不应该对实际依赖项进行版本控制。

1. 您不应该直接在Production上更新依赖项，因为您不知道这会如何影响代码的稳定性。新的依赖关系可能会引入错误，它可能会改变代码行为的方式，影响你自己的行为，它可能与其他依赖关系不兼容，等等。你应该在开发环境中完成这些工作，然后进行适当的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. 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.

你会看到一个关于不需要作曲家的论点。锁是你可以在你的作曲器中设置你需要的确切版本。Json文件，这样，每次有人运行composer install时，它都会为他们安装相同的代码。这是不对的，因为您的依赖项有它们自己的依赖项，并且它们的配置可能以允许更新到反版本，甚至可能是整个版本的格式指定。

这意味着即使您指定在编写器中使用Laravel 4.1.31。json, Laravel在它的作曲家。2.*. json文件可能需要它自己的依赖，如Symfony event-dispatcher: 有了这种配置，你可能会得到带有Symfony事件调度程序2.4.1的Laravel 4.1.31，而你团队中的其他人可能会得到带有事件调度程序2.6.5的Laravel 4.1.31，这一切都取决于你最后一次运行composer安装是什么时候。

有了作曲家。版本系统中的Lock文件将存储此子依赖项的确切版本，因此，当您和您的队友进行composer安装时(这是您将基于composer. Lock安装依赖项的方式)，您将获得相同的版本。

如果你想更新呢?然后在您的开发环境中运行:composer update，这将生成一个新的作曲器。锁文件(如果有新东西)，在你测试它，QA测试和回归测试之后。您可以推动它，让其他人下载新的作曲器。锁，既然安全升级。

3. You shouldn't version control your actual dependencies, because it makes no sense. With the composer.lock you can install the exact version of the dependencies and you wouldn't need to commit them. Why would you add to your repo 10000 files of dependencies, when you are not supposed to be updating them. 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.

如果你更新了你的库，你也想提交锁文件。它基本上说明您的项目被锁定到您正在使用的库的特定版本。

如果您提交了更改，并且有人提取了您的代码并更新了依赖项，那么锁文件应该是未修改的。如果它被修改了，这意味着您有了某个东西的新版本。

在存储库中使用它可以确保每个开发人员使用相同的版本。

如果你担心你的代码被破坏，你应该提交编写器。锁定您的版本控制系统，以确保所有项目合作者使用相同版本的代码。如果没有锁定文件，您每次都会得到新的第三方代码。

例外情况是当你使用元应用程序时，需要在安装时更新依赖关系的库(如Zend Framework 2 Skeleton应用程序)。因此，目标是在每次开始开发时获取最新的依赖项。

来源:作曲者:It’s All About the Lock File

请参见:编写器更新和安装之间的区别是什么?

在以两种方式做了几个项目后，我的立场是作曲家。Lock不应该作为项目的一部分提交。

作曲家。Lock是构建元数据，不是项目的一部分。依赖关系的状态应该通过您如何控制它们(手动或作为自动构建过程的一部分)来控制，而不是由上一个开发人员任意更新它们并提交锁文件。

如果你担心在编写器更新之间依赖关系的变化，那么你对自己的版本控制方案缺乏信心。版本(1.0、1.1、1.2等)应该是不可变的，你应该避免在初始特性开发之外使用“dev-”和“x *”通配符。

提交锁文件是依赖项管理系统的回归，因为依赖项版本现在已经回到隐式定义的状态。

此外，你的项目永远不应该在每个环境中重新构建或重新获取其依赖项，尤其是prodd。你的交付品(tar, zip, phar，一个目录等)应该是不可变的，并在环境中进行推广而不需要更改。

这一点在这里已经得到了充分的回答。

博士TL;

当然，你应该vc这个composer.lock

但我要告诉你的是为什么

作曲家。json的作用

作曲家。Json是PHP包的依赖项清单的入口点。

它已经规定包开发人员遵循语义版本控制。

因此，通过这种方式，如果X.Y.Z中的API版本(x)发生了更改，您将明白有一些事情需要注意，否则您可以将您的版本锁定到某个“~x”版本。

并非所有包都遵循semversion

但是，有很多包没有遵循规则(5.3和5.4 api级别改变或破坏):

不尊重semversioning原则(api级别更改) 新的包与旧的API不兼容(没有经过很好的测试和损坏)

解决方案composer.lock

作曲家想出了一个解决办法。另一个用于锁定包版本的文件。(composer.lock)

它保存了确切的包版本，因此如果任何人想拥有相同的依赖版本，都可以从它中受益。

在所有部署之间保持清单相同

值得一提的是，现代web开发原则的12个因素之一是在所有部署中保持依赖关系相同，这样每个部署都可以测试它。 它们之间没有收缩。

:

你必须留下作曲者。在版本控制下锁定

在生产方面:

composer install --no-dev

从vc控制的锁文件中安装所有东西。 你之前已经完全测试过了。

作曲家的最终用户。Json & composer.lock

作曲家。Json是开发人员总结deps和版本的精简文件。

而作曲家。Lock被部署程序(机器)用于在部署程序上安装准确的版本号。

类比

这就像IP和域名的类比:

供机器使用的IP(锁文件)

打算由人类使用的域(json)

然而，人(开发人员)和机器(部署人员)都可以从两者中读取并受益，但两者都有更可取的版本。

对于应用程序/项目:当然可以。

composer文档中强调了这一点:

提交应用程序的编写器。锁定(连同composer.json)到版本控制。

就像@meza说的:你应该提交锁文件，这样你和你的合作者就可以在同一组版本上工作，并防止你说“但它在我的电脑上工作”。: -)

对于图书馆:可能不会。

作曲家的文档中提到了这个问题:

注意:对于库，不一定建议提交锁文件(…)

并在这里声明:

对于你的库，你可以提交作曲家。如果你想锁定文件。这可以帮助您的团队始终针对相同的依赖版本进行测试。但是，这个锁文件不会对依赖于它的其他项目产生任何影响。它只对主要项目有影响。

对于图书馆，我同意@Josh Johnson的回答。