如何解决问题，当使用laravel框架处理同一项目的几个开发人员有不同的本地laravel/vendor/composer/*文件时？
想象一下，我们有一个生产服务器，我们不再运行作曲家了（或者我们应该？）。要将所有文件投入生产，开发人员必须在本地执行composer update，因此laravel会动态创建/更改文件夹vendor/composer/中的文件。比开发人员将这些文件提交到生产环境并且有效。
但在我的同事提交后，我想更新我的svn。这意味着它还将更新动态创建的文件，这些文件将错过例如我当前的工作更改。所以我必须在我的本地实例上运行composer update来实现同事的更改，并且还包括我当前的（仍然是非提交的）更改。
这是一个正常的好习惯，在每次svn更新后总是在localhost上运行composer update吗？
答案 0 :(得分：1)
很多问题，但我想我明白你的问题是什么。
首先确保您没有控制供应商目录版本。 composer.json和composer.lock都应该受版本控制。
如果有人通过编辑器安装了新的软件包，那么所有其他开发人员都应该安装＆＃34; composer install＆＃34;获得新代码后。
在制作中，您始终运行＆＃34; composer install＆＃34 ;, never＆＃34; composer update＆＃34;。
＆＃34;作曲家更新＆＃34;应该以受控方式运行，因为它的作用是使用新版本更新所有包（根据composer.json设置）。
答案 1 :(得分：1)
想象我们有一个生产服务器，我们不再运行作曲家（或者我们应该？）。
您应该在生产服务器上运行以下命令以部署新代码：
php artisan down
git pull origin master
composer install
php artisan migrate
php artisan up
你应该有＆＃39; composer.lock＆＃39;包含在您的版本控制中，以便所有开发人员（和生产服务器）使用相同版本的/ vendor文件
运行作曲家是否存在安全风险？
绝对不是 - 这是标准做法（假设你有composer.lock）。 Composer.lock确保您的服务器获得完全相同的文件。如果您查看composer.lock内部，您会看到诸如
之类的项目"url": "https://api.github.com/repos/briannesbitt/Carbon/zipball/cde7a00d1410a17fb6d61b993cb017a78be1137c",
如果一个有胆量的人要添加新版本的软件包，它就不会有相同的散列拉链位置 - 所以你仍然会收到你期望的正确版本。