下面由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 中再次进行内联别名。

注意：应避免使用内联别名，尤其是对于已发布的包 / 库。如果您发现了错误，请尝试将您的修复程序合并到上游，这有助于避免使用您包的用户出现问题。