我正在阅读/学习 Composer，它是 PHP 的应用程序级包管理器。
在此blog post由首席开发者 Jordi Boggiano 撰写，他写道:
Composer on the other hand forces you to declare your project dependencies in a one-stop location (composer.json at the root). You just checkout the code, install dependencies, and they will sit in the project directory, not disturbing anything else on the machine. Another related feature is the composer.lock file that is generated when you install or update dependencies. It stores the exact version of every dependency that was used. If you commit it, anyone checking out the project will be able to install exactly the same versions as you did when you last updated that file, avoiding issues because of minor incompatibilities or regressions in different versions of a dependency.
如果我正确理解 Composer，当我们谈论由 Composer 下载/安装的包时，我们指的是 PHP 代码包，即 用 PHP 编写的编程代码，而不是系统级的包，例如，对安装在服务器上的 PHP 运行时的扩展。因此，一旦这些 PHP 代码包被下载并添加到 PHP 项目中，我会认为这些包将成为 PHP 应用程序源代码的一部分，例如，被 checkin 项目所使用的版本控制系统。如果另一个开发人员过来检查代码，为什么他们需要像博客文章中所述那样“安装包”？当他们从源代码控制中 check out 代码时，他们不会得到所有代码包的副本吗？博文中的这一行让我感到困惑，让我觉得我不了解 Composer。
如能澄清这一点，我们将不胜感激。谢谢。
最佳答案
依赖项本身应该不提交给源代码管理。另一方面，composer.json 和 composer.lock 文件应该。这有多种原因，其中包括:
- 每次更新依赖项时，您都必须提交更改。这种方式将您的代码与依赖项紧密耦合，而实际上恰恰相反。
- 包本身已经在它们自己的存储库中，有它们自己的历史。为什么要在您的项目历史中重复这一点？
- 这些存储库可能庞大，只会搅乱您的项目。为什么要随身携带这么重的东西？
相反，让每个开发人员在 checkout 项目时只运行 composer install(非常重要:而不是 composer update)会更有效率。 Composer 将从 composer.lock 安装依赖项，确保每个运行相同提交的人都在完全相同的页面上。部署也是如此。
您可以阅读更多相关信息 here .
另一方面，在某些情况下，您必须提交您的包以解决问题，例如当您知道您将无法运行 composer在您的生产服务器(共享主机)上安装
关于Composer 安装的 PHP 包 - 它们应该在源代码管理中吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46029477/