我是Composer(getcomposer.org)的新手，如果我使用Composer在本地安装一个包，然后使用Git将我的代码库推送到生产服务器，我不确定它是如何工作的。我必须在生产服务器上再次运行Composer吗？
欢呼，J
设置项目时，将依赖项添加到本地项目目录中的composer.json文件中。
完成此操作后，您将需要运行composer更新。您也可以运行composer install，但是，在没有composer.lock文件的情况下，composer安装实际上运行composer-update。
Composer更新会执行并解析您正在使用的所有库的所有依赖项，将它们下载到/vender目录，创建一个自动加载器脚本并生成Composer.lock文件。
对于您的项目，您要做的是对composer.json和composer.lock文件进行版本设置。
在生产服务器上，您将始终运行composer install，这可以确保生产服务器上的库与您在开发过程中使用的库完全相同。
composer的安装速度也快得多，因为它不必完成所有的依赖关系管理工作，而且几乎总是可以提取特定的commit#。它不必查看版本字符串。因此，一旦服务器已经通过它一次，它通常是非常快的。
在开发过程中，您唯一应该运行composer更新的时候，是当您引入一个新库时，或者当您遇到底层库已更改的问题时，您知道需要让composer退出并重新计算依赖项。composer更新总是重新计算并下载任何可用库的最新修订，即使版本级别没有更改。这意味着某些东西有可能被破坏，因此需要进行尽可能完整的回归测试。简而言之，与你实际改变的东西无关的东西可能已经坏了，所以你只想在被迫的时候引入改变的潜力
当然，如果您确实引入了一个新库，那么您别无选择，只能运行composer更新。
一旦您运行composer更新，您的composer.lock文件将被更新(如预期的那样)，并且当您在其上运行composers安装时，生产服务器将接收此信息。
正如其他人所说，将供应商放在您的gitignore中。重点是，这些是您所依赖的外部库，但不属于您的项目，不应进行版本控制。在过去，有些人使用git子模块，这是一个你真正想要避免的大型PITA，更不用说子模块没有解决你所包含的库的依赖性。
这取决于您的工作方式。如果你像getcomposer.org所说的那样，忽略了"vendor"文件夹，那么你需要再次运行它。如果您正在对"vendor"文件夹进行版本控制，则不需要再次运行它。
请记住，composer将负责管理您的依赖项版本，因此不需要将您的依赖性文件置于版本控制之下。如果你把这些文件放在git下，你只会让你的存储库变得更大。
读取https://getcomposer.org/doc/01-basic-usage.md#installing-依赖关系。
为了澄清，当你忽略"供应商"文件夹时，Git不会跟踪文件夹下的文件，所以如果你克隆repo，它将像composer从未执行一样