我已经完成了Symfony2中的一个项目的一半。
我需要使用composer安装几个新的供应商捆绑包。
我已经拥有了版本控制中的所有内容（不包括日志、缓存和parameters.yml）（包括供应商文件夹）。
问题是，当使用composer更新时，它会删除更新的供应商文件夹中的.svn文件夹。所以现在基本上不可能提交（这不会给我一个工作副本错误）。
附加信息：我在本地工作，并提交到开发服务器，然后批准应用程序服务器。因此，它必须是完美的（不能在提交后仅在dev/application服务器上运行php composer安装或php compose器更新）。
我还尝试导出所有内容，并将其复制粘贴回回购中，但这也不起作用（索引页在本地损坏）。
关于供应商版本控制，最好的方法根本不是版本供应商。
您只需要对composer.json和composer.lock进行版本化。这可能会导致没有稳定版本的供应商或您不需要稳定版本的厂商出现问题（例如，具有特定提交的master）。
作为一个解决方案，您应该创建自己的（私有）供应商存储库（比如说您自己的包装学家）。作曲家有一个工具，叫做萨蒂斯。
https://github.com/composer/satis
所以我的建议是：
- 使用Satis创建一个私人存储库。您将需要的每个包都放在
satis.json中，每当您需要更新供应商的版本或添加新版本时，您只需修改satis.json并重建存储库 - 在项目的
composer.json中，您将新的专用存储库设置为唯一的存储库，并设置选项：packagist到false - 现在，每次运行
composer install时，它都将只使用您的专用存储库，因此速度很快，而且您总是确保每个环境都有相同的版本
-
两年前我也遇到过类似的情况。
我学到的惨痛教训是：在供应商内部编辑文件时，切勿。起初，我完全拒绝使用composer，并手动克隆了我需要的所有内容。后来，我决定分叉我需要编辑的项目，并引用我的分叉。
Composer支持私人GitHub转发-您不需要将其注册到Packagist即可工作。
您不应该将vendor目录保留在版本控制中。Symfony标准版就是这样做的，你应该遵循这一点。运行composer install命令应该是部署过程的一部分
不建议在代码库中包含供应商包，因此，如果您需要维护本地机器上使用的包的相同版本，最好的方法是在VCS中保留composer.lock，并在其他环境中仅运行composer-install。
此外，如果您希望产品部署是即时的，而不依赖于composer进程，您可以在开发服务器上运行composer install，并且在验证后，您可以使产品部署脚本从dev-env复制供应商文件夹。