应该作曲家。锁被提交到版本控制?

然后将composer.json提交到项目中，团队中的其他人可以运行composer install来安装项目依赖项。

锁定文件的目的是记录已安装的确切版本，以便可以重新安装。这意味着如果您的版本规范为1。*然后你的同事运行composer update，安装1.2.4，然后提交composer。锁文件，当你安装composer时，你也会得到1.2.4，即使1.3.0已经发布了。这确保了每个参与项目的人都有相同的版本。

这意味着，如果自上次安装编写器以来提交了任何东西，则如果没有锁定文件，您将获得新的第三方代码。

同样，如果您担心代码破坏，这也是一个问题。这也是为什么把作曲家看作是以作曲家为中心的重要原因之一。锁文件。

来源:# EYZ0。

提交应用程序的编写器。锁定(连同composer.json)到版本控制。这很重要，因为install命令检查锁文件是否存在，如果存在，它就下载指定的版本(不管什么编写器)。json表示)。这意味着任何建立项目的人都将下载完全相同版本的依赖项。您的CI服务器、生产机器、团队中的其他开发人员，所有东西和每个人都运行在相同的依赖项上，这减轻了仅影响部署的某些部分的潜在错误。即使你独自开发，在六个月后重新安装项目时，即使你的依赖项发布了许多新版本，你也可以确信安装的依赖项仍然可以工作。

来源:# EYZ0。

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

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

^{来源:Composer: It 's All About Lock File}

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

这个问题没有确切的答案。

一般来说，composer不应该做构建系统应该做的事情，你也不应该把composer放在上面。锁定VCS。作曲家可能会奇怪地把它写反了。最终用户而不是产品不应该使用锁文件。通常你的构建系统会保存快照、可重用的dirs等等，而不是每次都保存一个空的dir。从composer签出库的人可能希望该库使用锁，以便对库加载的依赖项进行测试。

另一方面，这会显著增加版本管理的负担，因为依赖关系将被严格锁定，因此几乎可以肯定每个库都需要多个版本。如果每个库可能都有一个稍微不同的版本，那么你需要一些多库版本支持，你也可以很快看到需要的依赖关系的大小，因此建议将它保留在叶子上。

考虑到这一点，我真的不认为锁文件是有用的库或您自己的workdirs。它只在我的构建/测试平台上使用，该平台支持任何外部获取的资产，只在需要时更新它们，为测试、构建和部署提供可重复的构建。虽然它可以保存在VCS中，但并不总是保存在源树中，构建树要么在VCS结构的其他地方，要么由其他系统在其他地方管理。如果它存储在VCS中，是否将其保留在与源代码树相同的回购中是有争议的，因为否则每次拉都可能带来大量的构建资产。除了生产/敏感凭证和膨胀之外，我很喜欢把所有的东西都安排在一个良好的回购中。

SVN比git做得更好，因为它不强迫你获取整个回购(尽管我怀疑git实际上也不是严格需要的，但对它的支持是有限的，它不常用)。简单的构建回购通常只是一个覆盖分支，你合并/导出构建树。有些人将外部资源合并到源树中，或者进一步分离外部、构建和源树。它通常有两个目的，构建缓存和可重复构建，但有时至少在某种程度上保持分离也可以轻松地允许新的/空白的构建和多个构建。

对此有许多策略，但没有一种特别适合持久化源代码列表，除非您在源代码树中保留外部源代码。

文件中还有哈希值，两个人更新包时如何合并?光这一点就足以让你认为这可能是误解了。

人们对锁文件提出的论点是他们对问题采取了非常具体和限制性的观点。想要可重复的构建和一致的构建?在VCS中包含供应商文件夹。然后，您还可以加快获取资产的速度，并且不必在构建期间依赖可能损坏的外部资源。除非绝对必要，否则我创建的构建和部署管道都不需要外部访问。如果你必须更新一个外部资源，那就只有一次。编码器试图实现的东西对于分布式系统是有意义的，除了前面提到的，它没有意义，因为它最终会导致库更新的依赖关系地狱，经常发生冲突，更新速度和最慢的更新包一样慢。

此外，我更新猛烈。每次开发时，我都会更新和测试所有内容。有一个非常非常小的窗口，显著的版本漂移潜入。实际上，当支持语义版本时，这往往是为作曲家准备的，你不应该有那么多兼容性问题或损坏。

在作曲家。Json你把你需要的包和他们的版本。您可以在那里锁定版本。然而，这些包也有动态版本的依赖关系，不会被作曲家锁定。json(虽然我不明白为什么你不能自己也把它们放在那里，如果你想要它们被版本锁定)，所以其他人运行composer安装得到一些不同的东西没有锁。你可能不太在意，也可能在意，这要看情况。你应该关心吗?可能至少有一点，足以确保您在任何情况下都能意识到它及其潜在影响，但如果您总是有时间先DRY run并修复任何更新的内容，那么它也可能不是问题。

编写器试图避免的麻烦有时并不存在，编写器锁文件可能带来的麻烦是显著的。他们绝对没有权利告诉用户他们应该或不应该做什么关于构建和源资产(是否加入或分开在风投)，因为这不关他们的事，他们不是你或我的老板。"作曲家说"不是权威，他们不是你的上级也不会在这个问题上给任何人任何优势。只有你自己知道你的真实情况，知道什么是最好的。然而，他们可能会为不了解事物如何工作的用户提供默认的行动方案，在这种情况下，您可能会想要遵循它，但我个人认为这并不能真正替代了解事物如何工作并能够正确地满足您的需求。最终，他们对这个问题的答案是最好的猜测。制作作曲家的人不知道你应该把作曲家放在哪里。他们也不应该锁上。他们唯一的责任就是告诉你它是什么，它能做什么。除此之外，你需要决定什么对你是最好的。

保留锁文件对于可用性是有问题的，因为作曲者对它是使用锁还是JSON非常保密，并且并不总是很好地同时使用这两种文件。如果你运行安装，它只使用锁文件，它会出现，所以如果你添加一些作曲。Json，那么它就不会被安装，因为它不在你的锁中。对于json/lock文件来说，操作的真正作用和作用并不直观，有时甚至看起来没有意义(帮助说安装需要一个包名，但试图使用它时，它说没有)。

要更新锁或应用json中的更改，你必须使用update，你可能不想更新所有内容。锁优先选择应该安装什么。如果有一个锁文件，它就是所使用的。你可以在一定程度上限制更新，但系统仍然一团糟。

更新需要一段时间，几gb的内存。我也怀疑，如果你拿起一个项目，它已经有一段时间没有被碰过了，从它的版本来看，随着时间的推移，它可能不会有效地做到这一点，这只是扼杀它。

当涉及到秘密的复合命令时，它们非常非常狡猾，你不能期望它是复合的。默认情况下，composer remove命令似乎映射到composer update和composer remove。

你真正需要问的问题不是你是否应该把锁保存在你的源树中，或者你是否应该以某种方式将它保存在某个地方，而是你应该问它实际上是做什么的，然后你可以自己决定什么时候需要将它保存在哪里。

我要指出的是，当你有一个强大的外部依赖持久性策略时，拥有锁的能力是非常方便的，因为它可以跟踪你的信息，用于跟踪(起源)和更新它，但如果你没有，那么它既不在这里也不在那里。当它作为强制选项强行进入您的喉咙以污染您的源树时，它是没有用处的。这在遗留代码库中很常见，人们对composer做了很多更改。Json还没有真正应用，当人们尝试使用composer时就会被破坏。没有作曲家。锁定，没有不同步问题。

是的很明显。

这是因为本地安装的编写器将优先选择编写器。在composer.json上锁定文件。

如果锁文件在vcs中不可用，composer将指向composer。Json文件来安装最新的依赖项或版本。

文件编写器。Lock更深入地维护依赖关系，即它指向我们软件中包含的包版本的实际提交，因此这是最重要的文件之一，它更精细地处理依赖关系。

对于任何在Heroku上的人来说，答案都是明确的“是的，它应该被承诺”:

如果composer.json在其require部分中指定了任何类型的依赖项，则运行composer update生成的相应的composer.lock也必须提交到存储库，否则推送将被拒绝。

来源:# EYZ0。

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

博士TL;

当然，你应该vc composer.lock

但我要讲的是为什么

作曲家。json的作用

作曲家。json是php包的依赖项清单的入口点。

它已经为包开发人员开出了遵循 语义版本控制的处方。

所以通过这种方式，如果x.y.z中的api版本(x)发生了变化，你就会明白有一些事情需要注意，否则你可以将你的版本锁定到"~x"版本。

并非所有包都遵循semversion

但是，有很多包不遵循规则(5.3 &5.4 API等级改变或损坏):

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

解决方案composer.lock

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

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

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

:

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

在生产方面:

composer install --no-dev

安装所有vc控制的锁文件。

作曲家的最终用户。json,composer.lock

composer.json是开发人员用来总结deps和版本的精简文件。

而composer.lock将被部署(机器)用于在部署上安装确切的版本号。

类比

它就像知识产权,域的类比:

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

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

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