这篇文章给大家分享的是有关使用别名的原因的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。
下面由composer教程栏目给大家介绍使用分支别名的原因,希望对需要的朋友有所帮助!
为什么要使用别名?
当你使用版本控制系统仓库时,你只能从那些看起来像版本的分支得到一个可比较的版本,例如 2.0 或 2.0.x 。对于 master 分支,你只能得到一个 dev-master 版本。对于 bugfix 分支,你将得到 dev-bugfix 版本。
如果你的 master 分支是用来标记 1.0 的开发流程,如 1.0.1 , 1.0.2 , 1.0.3 等,依赖于你的库的包可能需要的是 1.0.* 。
如果有人想要使用最新的 dev-master ,将会遇到一个问题:有的包可能需要的是 1.0.* ,所以这两个将会导致冲突,因为 dev-master 并不匹配 1.0.* 。
基于以上,别名出现了。
分支别名
dev-master 分支是主 VCS 仓库中的一个。有些人会想要最新的主开发版本,这是很常见的。因此,Composer 允许您将 dev-master 分支别名为 1.0.x-dev 版本。它是通过在 composer.json 中指定 extra 下的 branch-alias 字段来完成的:
{ "extra": { "branch-alias": { "dev-master": "1.0.x-dev" } } }
如果别名为不可比较的版本 (例如 dev-develop),则必须为分支名称添加前缀 dev- 。您也可以为可比较的版本添加别名(即以数字开头,以 .x-dev 结尾),但只作为更具体的版本。例如,1.x-dev 可以被别名为 1.2.x-dev。
别名必须是可比较的开发版本,并且 branch-alias 必须出现在它引用的分支上。对于 dev-master 您需要在 master 分支上提交它。
因此,很多人现在都需要 1.0.* 并且他将很乐意安装 dev-master 。
要使用分支别名,您必须拥有别名的包的存储库。如果要为第三方包添加别名而不维护它的分支,请使用,内联别名,如下所述。
需要内联别名
分支别名对于主要开发线非常有用。但是为了使用它们,您需要控制源存储库,并且需要提交对版本控制的更改。
当您想尝试某个库的错误修复时,这并不是很有趣,该库是本地项目的依赖项。
因此,您可以在 require and require-dev 字段中对包进行别名。假设您在 monolog/monolog 包中发现了一个错误。您在 GitHub 上克隆了 Monolog 并在一个名叫 bugfix 的分支中解决了这个问题。现在,您要在本地项目中安装该版本的 monolog 。
您使用的是 symfony/monolog-bundle ,需要 monolog/monolog 版本 1.* 。因此,您需要使用 dev-bugfix 来匹配该约束。
将其添加到项目的根 composer.json 中:
{ "repositories": [ { "type": "vcs", "url": "https://github.com/you/monolog" } ], "require": { "symfony/monolog-bundle": "2.0", "monolog/monolog": "dev-bugfix as 1.0.x-dev" } }
这将从您的 Github 获取 monolog/monolog 的 dev-bugfix 的版本,并将其别名为 1.0.x-dev 。
注意:内联别名是仅限 root 用户使用的功能。如果需要具有内联别名的包,则使用别名(as 的右侧)用作版本约束。 as 的左边部分被丢弃了。因此,如果 A 需要 B 和 B 需要 monolog/monolog 版本 dev-bugfix 为 1.0.x-dev ,则安装 A 也将使 B 也需要 1.0.x-dev ,其可能作为分支别名或实际的 1.0 分支存在。如果没有,则必须在 A 的 composer.json 中再次进行内联别名。
注意:应避免使用内联别名,尤其是对于已发布的包 / 库。如果您发现了错误,请尝试将您的修复程序合并到上游,这有助于避免使用您包的用户出现问题。
感谢各位的阅读!关于“使用别名的原因”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,让大家可以学到更多知识,如果觉得文章不错,可以把它分享出去让更多的人看到吧!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。