这篇文章给大家分享的是有关使用别名的原因的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。
下面由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 中再次进行内联别名。
注意：应避免使用内联别名，尤其是对于已发布的包 / 库。如果您发现了错误，请尝试将您的修复程序合并到上游，这有助于避免使用您包的用户出现问题。
感谢各位的阅读！关于“使用别名的原因”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
