composer.lock应该承诺版本控制？
我有一个与存储库的应用程序中使用的composer.lock有点困惑。
我看到许多人说，我们不应该从库中.gitignore composer.lock 。
如果我在我的开发环境中更新我的库，我将有一个新的composer.lock但我将无法将它们更新到生产，是吗？
它不会在这个文件上产生冲突吗？
如果你更新你的库，你也想提交锁文件。 它基本上说，你的项目被locking到你正在使用的库的特定版本。
如果您提交更改，并且有人拉取代码并更新依赖项，则locking文件应该是未修改的。 如果它被修改，这意味着你有一个新的东西版本。
在存储库中保证每个开发人员都使用相同的版本。
对于应用程序/项目 ：肯定是的。
composer php文档在这方面（重点）说明：
将你的应用程序的composer.lock（和composer.json一起）提交到版本控制中。
就像@meza说的：你应该提交locking文件，这样你和你的协作者正在使用同一套版本，并阻止你使用类似“但它在我的电脑上工作”的说法。 😉
对于图书馆 ：可能不是。
composer php文档logging在这个问题上：
注意：对于库，不一定build议提交locking文件（…）
在这里指出：
对于你的库你可以提交composer.lock文件，如果你想。 这可以帮助您的团队始终对相同的依赖版本进行testing。 但是，这个locking文件不会对依赖它的其他项目产生任何影响。 这只对主要项目有影响。
对于图书馆，我同意@Josh Johnson的回答。
在做了几个项目的两种方式后，我的立场是composer.lock不应该作为项目的一部分提交。 我知道这样做比较容易，但请在我提出这个问题的时候请耐心等待。
composer.lock是构build元数据，而不是项目的一部分。 依赖关系的状态应该通过如何对它们进行版本控制来控制（无论是手动还是作为自动构build过程的一部分），而不是由最后一个开发人员任意更新它们并提交locking文件。
如果您担心您的composer php更新之间的依赖关系发生变化，那么您对版本控制scheme缺乏信心。 版本（1.0,1.1,1.2等）应该是不可变的，你应该在初始特性开发之外避免使用“dev-”和“X. *”通配符。
提交locking文件是依赖关系pipe理系统的回归，因为依赖关系版本现在已经回到隐含定义的状态。
而且，你的项目不应该被重build，或者在每个环境中重新获得依赖，特别是产品。 你的可交付成果（tar，zip，phar，目录等）应该是不变的，并且可以在不改变状态的情况下通过环境进行升级。
编辑：我知道，这不会是一个受欢迎的答案，但如果你投票，你是否会提供一个理由，在评论中指出了答案的缺陷？ 谢谢！
- 您不应直接在生产上更新您的依赖关系。
- 你应该版本控制你的composer.lock文件。
- 你不应该版本控制你的实际依赖。
1.你不应该直接在Production上更新你的依赖关系 ，因为你不知道这将如何影响你的代码的稳定性。 可能会有新的依赖关系引入错误，它可能会改变代码的行为影响你自己的方式，它可能与其他依赖关系不兼容等。你应该在开发环境中做这个，然后进行适当的QA和回归testing等等。 。
2.您应该版本控制您的composer.lock文件 ，因为这存储了有关您的依赖项的信息以及您的依赖关系的依赖关系，这将允许您复制代码的当前状态。 这很重要，因为所有的testing和开发都是针对特定的代码完成的。 不关心你的代码的实际版本类似于上传代码更改到你的应用程序，而不是testing它们。 如果你正在升级你的依赖版本，这应该是一个愿意行动，你应该采取必要的照顾，以确保一切仍然有效。 失去一个或两个小时的恢复时间恢复到以前的版本可能会花费你很多钱。
您将会看到不需要composer.lock的一个参数是，您可以在composer.json文件中设置所需的确切版本，并且这样每次有人运行composer install ，都会安装它们相同的代码。 这是不正确的，因为你的依赖关系有它们自己的依赖关系，并且它们的configuration可能被指定为允许更新子版本甚至整个版本的格式。
这意味着，即使在composer.json中指定了Laravel 4.1.31，其composer.json文件中的Laravel也可能具有自己的依赖项，如Symfony event-dispatcher：2. *。 通过这种configuration，你可以用Laravel 4.1.31和Symfony event-dispatcher 2.4.1，而你的团队中的其他人可以用Laravel 4.1.31来调用2.6.5的事件调度器，这一切都取决于什么时候是您最后一次运行composer php安装。
因此，将版本系统中的composer.lock文件存储在这个子依赖关系的确切版本中，所以，当你和你的队友做一个composer php安装时（这是你将安装你的依赖关系的方式） 。locking ）你们都会得到相同的版本。
如果你想更新呢？ 然后在你的开发环境中运行： composer update ，这将会生成一个新的composer.lock文件（如果有新的东西的话），然后在你testing之后，进行QAtesting和回归testing。 您可以推送给其他人下载新的composer.lock ，因为它可以安全地升级。
3.你不应该版本控制你的实际依赖 ，因为这是没有意义的。 使用composer.lock，你可以安装依赖关系的确切版本，你不需要提交它们。 你为什么要添加到你的回购10000文件的依赖，当你不应该更新它们。 如果你需要改变其中的一个，你应该分叉它并在那里进行修改。 如果您担心每次构build或发布时都需要获取实际的依赖关系，那么composer php有不同的方法来缓解这个问题，caching，压缩文件等等。
然后将
composer.json提交到您的项目中，并且团队中的其他人可以运行composer install来安装项目依赖项。locking文件的要点是logging已安装的确切版本，以便可以重新安装。 这意味着，如果您的版本规格为1. *，而您的同事运行安装了1.2.4的composer php更新，然后提交composer.lock文件，则当您composer php安装时，您还将获得1.2.4，甚至如果1.3.0已经发布。 这确保在项目上工作的每个人都有相同的确切版本。
这意味着如果从上一次composer php安装完成之后已经提交了任何内容，那么在没有locking文件的情况下，您将获得新的第三方代码被下拉 。
再一次，如果你担心你的代码被破坏，这是一个问题。 这也是为什么把Composer视为以composer.lock文件为中心的重要原因之一。
来源： composer php：这是所有关于locking文件 。
将你的应用程序的composer.lock（和composer.json一起）提交到版本控制中。 这一点很重要，因为install命令会检查locking文件是否存在，如果是，则下载指定的版本（无论composer.json如何）。 这意味着任何设置项目的人都会下载完全相同的版本。 您的CI服务器，生产计算机，团队中的其他开发人员，所有人和每个人都运行相同的依赖关系，从而减less了仅影响部分部署的错误的可能性。 即使你独自开发，在重新安装项目的六个月内，即使你的依赖项从那以后发布了许多新的版本，你仍然可以确信安装的依赖项依然有效。
来源： composer php – 基本用法 。
如果您担心代码中断，则应将composer.lock提交给您的版本控制系统，以确保您的所有项目协作者都使用相同版本的代码。 如果没有locking文件，每次都会得到新的第三方代码。
当你使用元应用程序时，例外情况是应该在安装时更新依赖项（比如Zend Framework 2 Skeleton App ）。 所以我们的目标是在每次想要开始开发的时候抓住最新的依赖关系。
来源： composer php：这是所有关于locking文件
另请参见： composer php更新和composer php安装之间有什么区别？
