Adi*_*tol 8 php git-submodules composer-php
我已经安装了composer并通过'composer install'添加了一些包.它将它们安装在"my_project\vendor"路径下,但是一些软件包是使用git克隆的,所以当我提交"my_project"时,这些克隆的软件包被忽略了.
问题是,当其他开发人员克隆"my_project"时,他们会丢失被忽略的包.有没有办法自动将包添加到"my_project",以便其他开发人员从我这里获取它们？
我认为这应该使用子模块完成,但我不知道如何自动将作曲家的每个新包作为子模块添加到我的项目中.
Mar*_*ope 13
前言:Jordi - 我喜欢作曲家,保持伟大的工作,如果我错了任何这个让我知道,我将更新我的工作流程并编辑帖子:D
不幸的是,这不是"一般建议",取决于你问的是谁,这是迄今为止只有开发人员的观点.使用作曲家常见问题解答中规定的练习的注意事项有很多考虑因素,而不是我在这里可以讨论的.因此,我会留下几个重点来考虑其他人.
@ Seldaek 自己的录取作曲家并非真正100%稳定,远比一年前好,但无论如何仍然是一个非常活跃的项目.因此,依靠composer在开发服务器与登台服务器与生产服务器之间实现相同的环境不是任何QA/Deployment组的一般建议.这对Jordi来说并不意味着轻微,而是QA人民的一丝不苟的表现.
从FAQ中可以看出,在将供应商库合并到您自己的存储库时,您应该:
限制自己安装标记版本(没有开发版本)
但是,如果您使用composer来管理CI或自动部署,则会应用相同的约束 - 只会更多 - 因为将master或dev标记部署到生产环境可能与您在一天中仅进行测试时所测试的包非常不同甚至一个小时前.
即使在第三方库中引入的更改之外(无论开发还是生产部署,都可以通过仅使用标记版本来解决),除非您每次都能依靠作曲家完成相同的操作,否则您将冒险将错误引入生产.这不是我真正关心的风险案例,但是我也是一个开发人员;)但问题可能来自这样的简单更改,除非你在所有环境中维护完全相同版本的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来部署您的软件.
| 归档时间： |
|
| 查看次数： |
5681 次 |
| 最近记录： |