完成此操作后,您将需要运行composer update.您也可以运行composer install,但是,如果没有composer.lock文件,composer install实际上会运行composer update.

Composer更新将解析您正在使用的所有库的所有依赖项,将它们下载到/ vendor目录,创建自动加载器脚本并生成composer.lock文件.

对于您的项目,您想要做的是使用composer.json和您的composer.lock文件.

在生产服务器上,您将始终运行composer install,这可确保生产服务器上的库与您在开发过程中使用的库完全相同.

composer install也快得多,因为它不需要完成所有依赖项管理工作,并且几乎总是可以只提取特定的提交#.它不必查看版本字符串.因此,一旦服务器已经通过它一次,通常非常快.

在开发中,唯一一次应该运行composer update,就是当你引入一个新库时,或者你有一个问题,即底层库已被更改,你知道你需要让composer出去并重新计算依赖项.即使版本级别没有更改,composer update也会重新计算并下载任何可用库的最新版本.这意味着某些东西有可能被破坏,因此有可能像您可能获得的那样完整的一组回归测试.简而言之,与你实际改变的东西无关的东西可能已经破裂了,所以你只想在被迫时引入改变的可能性.

当然,如果你确实介绍了一个新的库,你别无选择,只能运行composer update.

运行composer update后,您的composer.lock文件将被更新(如预期的那样),并且当您在其上运行composer install时,生产服务器将选择此文件.

正如其他人所说,将供应商放在您的gitignore中.关键是这些是你依赖的外部库,但它们不属于你的项目,不应该被版本化.在过去,有些人使用gIT子模块,这是你真正想要避免的一个大PITA,更不用说子模块不能解决你所包含的库的依赖性.