• 为什么使用别名？
• 分支别名
• 内联别名需求

别名#

为什么使用别名？#

当您使用 VCS 仓库时，您只会获得与版本相似的分支的可比较版本，例如 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 和 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"
    }
}

或者让 Composer 为您添加它：

php composer.phar require "monolog/monolog:dev-bugfix as 1.0.x-dev"

这将从您的 GitHub 获取 monolog/monolog 的 dev-bugfix 版本，并将其别名为 1.0.x-dev。

注意： 内联别名是根目录专用的功能。如果需要带有内联别名的包，则别名（as 右侧）用作版本约束。as 左侧的部分将被丢弃。因此，如果 A 需要 B，而 B 需要 monolog/monolog 版本 dev-bugfix as 1.0.x-dev，则安装 A 将使 B 需要 1.0.x-dev，它可能作为分支别名或实际的 1.0 分支存在。如果没有，则必须在 A 的 composer.json 中再次内联别名。

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

发现错误了吗？文档中有什么问题吗？分叉并编辑它！