我已经安装了作曲家并通过“作曲家安装”添加了一些软件包。它将它们安装在“my_project\vendor”路径下，但是一些包是使用 git 克隆的，所以当我提交“my_project”时，那些克隆的包被忽略了。
问题是当其他开发人员克隆“my_project”时，他们会丢失被忽略的包。有没有办法自动将包添加到“my_project”，以便其他开发人员从我这里获取它们？
我认为这应该使用子模块来完成，但我不知道如何自动将 composer 中的每个新包作为子模块添加到我的项目中。
问问题
5832 次
2 回答
13
前言：Jordi - 我喜欢作曲家，继续努力，如果我在这方面有误，请告诉我，我会更新我的工作流程并编辑帖子：D
不幸的是，这不是“一般建议”，具体取决于您询问的对象，到目前为止，这只是开发人员的观点。使用作曲家常见问题解答中规定的练习的注意事项比我在这里可以涵盖的要多得多。因此，我将留下几个要点供其他人考虑。
@Seldaek自己承认作曲家并不是 100% 稳定，比一年前要好得多，但无论如何仍然是一个非常活跃的项目。因此，依靠作曲家在开发服务器、登台服务器和生产服务器上实现相同的环境并不是任何 QA / 部署组的一般建议。这并不是对 Jordi 的轻视，而是对 QA 人民一丝不苟的天性的一种表达。
从常见问题解答中，它指出将供应商库合并到您自己的存储库时，您应该：
限制自己安装标记版本（无开发版本）
但是，如果您使用 composer 来管理您的 CI 或自动化部署，那么同样的约束将适用 - 只是更是如此- 因为将 master 或 dev 标签部署到您的生产环境可能是一个非常不同的包，而不是您在暂存一天或甚至一个小时前。
即使在第三方库中引入的更改之外（这将通过仅使用标记版本来解决，而不管开发或生产部署如何）除非您可以依赖作曲家每次都做完全相同的事情，否则您将冒着将错误引入生产的风险。这不是我真正关心的风险案例，但我也是一名开发人员；）但是问题可能来自像这样的简单更改，除非您在所有环境中维护完全相同版本的 composer.phar，你真的可以搞砸一个登台或生产服务器。
我遇到的另一个主要问题确实与此标题下列出的所有要点有关：
虽然在某些环境中提交它可能很诱人，但它会导致一些问题：
我不认为后果是问题，而是利益！在现代高带宽环境中，大型 vcs 存储库并不是什么大不了的事。除非您使用非常活跃的供应商库，否则您的差异也不会那么大。即使它们很大，git/hg/dvcs 系统都能够重用块、压缩块并将所有鸭子排成一排。但更重要的是，当对这些包进行更改时，它们会向开发人员发出警报，并且diff -w是对全部更改集的一个很好的总结视图，尤其是当您使用 dev/master 标签时。
在您自己的 VCS 中复制所有依赖项的历史记录。
这措辞有点不正确，它不会复制供应商库的整个提交历史，只是一个提交（您的提交）覆盖从现在到最后一次运行作曲家更新导致更改的完整增量。您可能不会在每次更新时更新所有库，即使您没有指定单独的包。如果您确实不小心更新了供应商库，您可以轻松恢复，而如果您在 dev/master 标签上这样做并且它破坏了您的环境，您必须弄清楚您之前使用的版本并在其中指定标签composer.json，并再次更新以恢复它。 git checkout /vendor/3rdpartylib --force对我来说似乎更容易。
将通过 git 安装的依赖项添加到 git repo 会将它们显示为子模块。这是有问题的，因为它们不是真正的子模块，您会遇到问题。
理想情况下，composer 会给你一个配置选项。它可以自动从 git pulls 中删除 .git 目录，并在更新 lib 之前自动 rm 目录（或临时 mv ），当且仅当更新版本存在时。这样做比将手动过程留给单个开发人员要可靠得多。将供应商库集成到您的版本控制存储库中有相同数量的原因，因此选择实际上取决于您的具体情况。
对所有文件进行版本控制的最大原因是能够可靠地将您在开发中测试的确切包部署到生产阶段，这是 vcs 和自动化部署开始的关键目的。除非您将开发环境配置为对每个包使用特定标签并且您对 composer.phar 进行版本控制，否则您不应依赖 composer 来部署您的软件。
于 2013-03-07T23:20:38.987 回答
13
理想情况下，您应该将 vendor/ 添加到您的 .gitignore 中，然后项目的每个开发人员都将运行 composer install 以获取供应商的设置。
您可以阅读有关提交供应商的常见问题解答条目以获取更多详细信息。
于 2012-07-17T10:03:18.267 回答