Azure DevOps 服务 |Azure DevOps Server |Azure DevOps Server 2022
在本文中，了解如何在将 Azure Boards 项目与 GitHub 存储库连接后，将工作项链接到 GitHub 提交、拉取请求、分支和构建。 可以使用#mention语法用于提交和分支，使用! 提及可以从工作项讨论中引用GitHub的拉取请求，或者直接从Azure Boards工作项中添加GitHub提交、拉取请求或分支的链接。
Note
GitHub集成支持：
- Azure DevOps Services：通过用于GitHub的 Azure Boards 应用与 GitHub.com 和 GitHub Enterprise Server 存储库集成。
- Azure DevOps Server 2020 及更高版本：仅支持与 GitHub Enterprise Server 存储库集成。
- 其他 Git 存储库：不支持集成。
Prerequisites
| Category | Requirements |
|---|---|
| 权限 | Contributor至Azure Boards项目和GitHub存储库的贡献者。 |
| 项目连接 | Azure Boards项目已连接至 GitHub 存储库，其中有您想要链接的提交、拉取请求和分支。 有关详细信息，请参阅 Azure Boards-GitHub 集成。 |
Note
若要查看“开发”部分和GitHub链接类型，使用托管 XML 进程模型的项目需要更新工作项类型。 有关详细信息，请参阅 用于选择工作项类型的更新 XML 定义。
使用 AB# 从 GitHub 链接到 Azure Boards 工作项
在GitHub提交、拉取请求或问题中，使用以下语法创建指向Azure Boards工作项的链接。 在提交消息的文本中输入 AB#ID。 或者，对于拉取请求或问题，请在说明中输入 AB#ID。 在注释或拉取请求标题中使用 AB#ID 不会在工作项上生成链接。
AB#{ID}
例如，AB#125 链接到工作项 ID 125。
还可以输入提交或拉取请求消息以转换工作项。 系统识别{state}或{state category}，以及fix、fixes、fixed，并将其应用于后续的#-mention项目。
例如，当拉取请求说明包含有效的状态名称时， Closed AB#1234系统将引用的工作项更新为该特定状态。 如果无法直接识别状态名称，Azure Boards尝试将其与工作流类别（如 Resolved 或 Completed）匹配。 如果找到匹配项，则工作项将转换为在该类别下定义的第一个可用状态。
默认情况下，使用 fix、fixes 或 fixed 引用的工作项会转换为与 已解析 类别关联的第一个状态。 如果当前进程中不存在此类状态，系统将工作项转换为 “已完成 ”类别中的第一个状态。
Important
你仍然可以链接工作项并指向其他分支，但状态转换规则只有在合并请求被合并到默认分支后才适用。
有关详细信息，请参阅工作流类别状态在 Azure Boards 积压和看板中的使用方式。
请查看下表中的示例：
| 提交或拉取请求消息 | Action |
|---|---|
Fixed AB#123 |
链接并将工作项转换为 “已解决 的工作流状态”类别;如果未定义，则为 “已完成 ”工作流状态类别。 |
Closed AB#123 |
链接并将工作项转换为 “已关闭 ”工作流状态。 如果没有定义，则不进行转换。 |
Adds a new feature, fixes AB#123. |
链接并将工作项转换为 “已解决 的工作流状态”类别;如果未定义，则为 “已完成 ”工作流状态类别。 |
Fixes AB#123, AB#124, and AB#126 |
指向 Azure Boards 的工作项 123、124 和 126 的链接。 仅将第一项（123）转换为 “已解析 的工作流状态”类别;如果未定义，则转换 “已完成 ”工作流状态类别。 |
Fixes AB#123, Fixes AB#124, Fixes AB#125 |
指向 Azure Boards 工作项 123、124 和 126 的链接。 将所有项转换为“已解析”工作流状态类别；如果未定义任何工作流状态类别，则转换为“已完成”工作流状态类别。 |
Fixing multiple bugs: issue #123 and user story AB#234 |
GitHub问题123和Azure Boards工作项234的链接。 不进行转换。 |
Note
如果将同一GitHub存储库连接到两个或多个Azure DevOps组织中定义的项目，则可能会看到意外的 AB# 提及链接。 有关详细信息，请参阅 解决连接问题。 因此，建议仅将GitHub存储库连接到单个Azure DevOps组织中定义的项目。
在拉取请求说明中使用 AB# 添加指向工作项的链接时，这些链接将显示在GitHub拉取请求的 Development 节中。 只有在拉取请求说明中使用 AB# 时，这些链接才可用。 如果直接从工作项链接到拉取请求，它们不会出现。 从说明中删除 AB# 引用也会从“开发”部分删除该引用。
从工作项创建GitHub分支
若要直接从工作项创建GitHub分支，请使用以下步骤：
在开发板中，找到要用于创建GitHub分支的工作项。
选择
工作项操作>新建 GitHub 分支。
在 创建GitHub分支对话框中，输入分支名称。 选择GitHub存储库和基分支。
选择 创建。
Azure Boards在指定的GitHub存储库中创建分支，并将其链接到工作项。 有关详细信息，请参阅 Azure Boards-GitHub 集成。
将工作项链接添加到GitHub分支、提交或拉取请求
打开工作项并转到 “开发 ”区域。
选择“添加链接”。 从每个下拉菜单中，选择link 类型、GitHub存储库和GitHub拉取请求。 可以在存储库中搜索和向下钻取，以查找并选择特定的拉取请求或提交，而无需复制和粘贴 URL。
选择“添加链接”。
Azure Boards检查以确认您输入的是有效的链接。 链接到的GitHub存储库必须连接到Azure Boards项目，否则验证将失败。
Note
如果使用 Azure DevOps Server 和 GitHub Enterprise Server，则完成 AB# 链接时存在延迟。 此过程使用“推送和拉取”设计，每小时从GitHub事件中拉取提交、PR 和问题上的增量更改。
自动链接更新
多个事件自动更新工作项窗体上的链接，因此无需手动创建它们。 这些事件包括：
| GitHub事件 | Action |
|---|---|
| 链接到分支 | 从分支创建拉取请求时，它会自动链接到工作项。 |
| 合并提交 | 合并拉取请求后，生成的合并提交会自动链接到工作项。 |
| 删除分支 | 如果删除分支（通常在合并后），则其链接会自动从工作项中删除。 |
查看或打开“开发”部分中的链接
工作项窗体中的“开发”部分列出了使用 
GitHub 图标创建 GitHub 提交和拉取请求的链接。
选择链接以在 GitHub 中打开提交或拉取请求。
GitHub拉取请求洞察
“开发”部分中的链接GitHub拉取请求显示额外的状态详细信息，因此无需在GitHub中打开拉取请求即可评估进度。
拉取请求洞见的先决条件
若要查看拉取请求的分析，请转到 GitHub 中的 Azure Boards 应用，并接受更新后的对检查功能的读取和写入访问权限。
查看拉取请求状态详细信息
打开一个与 GitHub 拉取请求相关联的工作项。
在 “开发 ”部分中，找到链接的拉取请求。 拉取请求链接旁边会显示以下状态详细信息：
- 草稿状态：显示拉取请求是否仍然是草稿。
- 评审状态：显示拉取请求需要评审、已批准还是已请求更改。
- 检查状态：显示 CI 检查是通过、失败还是挂起。
将鼠标悬停在状态指示器上以查看更多详细信息，或选择拉取请求链接以直接在GitHub中打开它。
使用 ! 提及GitHub拉取请求
使用 ! 提及来直接从任何工作项的富文本栏目或讨论注释中引用和讨论 GitHub 的拉取请求。 在文本字段中键入 ! 时，将显示一个选取器，可用于从连接的存储库中搜索并选择GitHub拉取请求。 所选拉取请求作为可单击链接插入。
使用此功能可以轻松地在工作项说明、验收条件或讨论线程中引用相关的拉取请求，而无需手动复制 URL。
查看 YAML 管道的生成状态（在生成中集成）
使用 Azure Pipelines YAML 构建托管在 GitHub 存储库中的代码时，可以在关联的工作项上自动生成 在生成时集成 链接。 此功能为GitHub存储库提供构建可追溯性，实现与Azure Repos相同的使用体验。
启用此功能：
打开 YAML 管道，选择“
更多操作”，然后选择“ 设置”。在管道设置对话框中，启用自动链接此生成中的新工作项。
生成完成后，每个关联的工作项的“开发”部分会自动显示集成生成链接，使团队能够完全跟踪工作项的生成。
有关配置此设置的详细信息，请参阅 配置管道以支持工作跟踪。
在板上查看GitHub对象
通过在面板上启用GitHub批注功能，您可以快速打开已链接的GitHub提交、拉取请求或问题，以获取更多详细信息。 有关详细信息，请参阅 自定义卡片。
