我已经安装了composer并通过'composer install'添加了一些包。它将它们安装在“my_project \ vendor”路径下，但是一些软件包是使用git克隆的，所以当我提交“my_project”时，这些克隆的软件包被忽略了。
问题在于，当其他开发人员克隆“my_project”时，他们会忽略被忽略的软件包。有没有办法自动将软件包添加到“my_project”，以便其他开发人员从我这里获取它们？
我认为这应该使用子模块完成，但我不知道如何自动将作曲家的每个新包作为子模块添加到我的项目中。
答案 0 :(得分：13)
理想情况下，您应该将vendor /添加到.gitignore，然后项目的每个开发人员都会运行composer install来让供应商进行设置。
您可以阅读提交供应商的FAQ entry了解更多详情。
答案 1 :(得分：13)
前言：Jordi - 我喜欢作曲家，保持伟大的作品，如果我误解了这一点，请告诉我，我将更新我的工作流程并编辑帖子：D
不幸的是，这不是“一般建议”，取决于你问的是谁，这是迄今为止只有开发人员的观点。使用作曲家常见问题解答中规定的练习的注意事项有很多考虑因素，而不是我在这里可以讨论的。所以我会留下几个要点供其他人考虑。
作者@ Seldaek的own admission作曲家并非真正100％稳定，远比一年前好，但仍然是very active project无论如何。因此，依靠composer在开发服务器与登台服务器与生产服务器之间实现相同的环境不是任何QA / Deployment组的一般建议。这对Jordi来说并不意味着轻微，而是QA人民的一丝不苟的表现。
从FAQ中，它说明了将供应商库合并到您自己的存储库时，您应该：
限制自己安装标记版本（无开发版本）
但是，如果您使用composer来管理CI或自动部署，则会应用相同的约束 - 仅更多 - 因为将master或dev标记部署到生产环境可能是非常不同于您在一天甚至一小时前的试验中测试的包。
即使在第三方库中引入的更改之外（无论开发还是生产部署，都可以通过仅使用标记版本来解决），除非你可以依靠作曲家每次完成同样的事情，否则你将冒险将错误引入生产。这不是我真正关心的风险案例，但我再次也是开发人员;）但问题可能来自simple changes like this，除非你在所有环境中维护完全相同版本的composer.phar ，你真的可以破坏一个升级或生产服务器。
我遇到的另一个主要问题实际上与本标题下列出的所有要点有关：
虽然在某些环境中提交它可能很诱人，但它会导致一些问题：
我不认为后果是问题，而是好处！在现代高带宽环境中，大型vcs存储库并不是一件大事。除非您使用非常活跃的供应商库，否则您的差异也不会那么大。即使它们很大，git / hg / dvcs系统都能够重新使用块，压缩块并保持所有的鸭子连续。但更重要的是，当对这些软件包进行更改时，它们会向开发人员发出警报，而diff -w是对总变更集的一个很好的摘要视图，如果您使用dev / master，则尤其是标签
在您自己的VCS中复制所有依赖项的历史记录。
这有点错误，它不会复制供应商lib的整个提交历史记录，只是一个提交（您的提交）覆盖现在和上次运行作曲家更新之间的完整增量导致更改。即使您没有指定单个软件包，也可能不会在每次更新时更新所有库。如果您不小心更新了供应商库，您可以轻松还原，而如果您在dev / master标签上这样做并且它破坏了您的环境，您必须弄清楚您以前使用的版本并指定标签composer.json，并再次更新以还原它。 git checkout /vendor/3rdpartylib --force对我来说似乎更容易。
将通过git安装的依赖项添加到git repo会将它们显示为子模块。这是有问题的，因为它们不是真正的子模块，你会遇到问题。
理想情况下，作曲家会给你一个配置选项。它可以自动从git pulls中删除.git目录，并在更新lib之前自动rm目录（或临时mv），当且仅当存在更新版本时。这样做比将手动流程留给个别开发人员要可靠得多。将供应商库集成到您的版本控制仓库中的原因相同，因此选择实际上取决于您的具体情况。
对所有文件进行版本控制的最大原因是能够可靠地将您在开发中测试的确切软件包部署到生产阶段，这是vcs和自动部署的关键目的。除非您将开发环境配置为对每个包使用特定标记，并且您对composer.phar进行版本控制，否则您不应该依赖composer来部署您的软件。