composer.lock应该致力于版本控制吗？
我对使用存储库的应用程序中使用的composer.lock有点困惑。
我看到很多人说我们不应该从库中.gitignore composer.lock 。
如果我在我的开发环境中更新我的库，我将有一个新的composer.lock但我无法将它们更新到生产中，对吗？
它不会在这个文件上产生冲突吗？
如果你更新你的库，你也想提交锁文件。 它基本上表明你的项目被锁定到你正在使用的库的特定版本。
如果您提交更改，并且有人拉取代码并更新依赖项，则锁定文件应该未修改。 如果它被修改，这意味着你有一个新版本的东西。
将其存储在存储库中可以确保每个开发人员都使用相同的版本。
对于应用程序/项目 ：肯定是的。
作曲家文档在这方面阐述（重点）：
将你的应用程序的composer.lock（和composer.json一起）提交到版本控制中。
就像@meza说的那样：你应该提交锁文件，这样你和你的协作者就可以使用同一套版本，并且防止你使用类似“但它在我的电脑上工作”的说法。 ;-)
对于图书馆 ：可能不是。
作曲家关于这件事的文件记录：
注意：对于库，不一定建议提交锁定文件（...）
并在此声明：
对于你的库，如果你愿意，你可以提交composer.lock文件。 这可以帮助您的团队始终对相同的依赖版本进行测试。 但是，这个锁定文件不会对依赖它的其他项目产生任何影响。 它只对主项目有影响。
对于图书馆，我同意@Josh Johnson的回答。
在做了几个项目的两种方式后，我的立场是composer.lock不应该作为项目的一部分提交。 我知道这样做比较容易，但请在我为此提出诉讼的同时忍受。
composer.lock是构建元数据而不是项目的一部分。 应该通过对它们进行版本控制（手动或作为自动构建过程的一部分）来控制依赖关系的状态，而不是由最后一位开发人员任意更新它们并提交锁定文件。
如果您担心您的作曲家更新之间的依赖关系发生变化，那么您对版本控制方案缺乏信心。 版本（1.0,1.1,1.2等）应该是不可变的，您应该在初始功能开发之外避免使用“dev-”和“X. *”通配符。
提交锁定文件是您的依赖关系管理系统的回归，因为依赖关系版本现在已经回到隐含定义。
另外，你的项目不应该被重建或者在每个环境中都需要依赖，特别是产品。 您的交付物（tar，zip，phar，目录等）应该是不可变的，并且可以在不改变状态的情况下通过环境进行推广。
编辑：我知道，这不会是一个受欢迎的答案，但如果你投下了票，你是否会提供足够的评论意见中的理由来指出答案中的缺陷？ 谢谢！
链接地址: http://www.djcxy.com/p/35485.html