练习 - 创建拉取请求

12 分钟

在本单元中，你将练习如何提交拉取请求并将更改合并到 main 分支，使每个人都可从你的工作中受益。

在使用 Azure Pipelines 创建生成管道中，你创建了一个名为 build-pipeline 的 Git 分支，你在其中为 Space Game 网站定义了一个基本生成管道。回想一下，你的生成定义位于名为 azure-pipelines.yml 的文件中。

虽然你的分支产生生成工件，但该工作仅存在于 build-pipeline 分支上。你需要将分支合并到 main 分支中。

回想一下，拉取请求告诉其他开发人员你已准备好代码，在必要时可以进行评审，并且你希望将更改合并到另一个分支（例如 main 分支）。

在我们开始之前，让我们先和 Mara 和 Andy 确认一下。

Andy：你好，Mara。我知道你已在 Azure 上运行生成管道。我正在向网站添加一个功能，我想亲眼看看生成过程。我们准备好了吗？

Mara：当然。我在分支上创建了管道。为什么我们不创建拉取请求并将其合并到 main，以便你也可以使用管道？

Andy：听起来不错。让我们一起看一下。

创建分支并添加起始代码

尽管可以使用在上一个模块中构建的生成管道，但让我们创建一个名为 code-workflow 的新分支。此分支基于 main，因此可以从头开始练习该过程。

在 Visual Studio Code 中打开集成终端。
切换到 main 分支：
```
git checkout main
```
确保你具有 GitHub 中最新版本的代码：
```
git pull origin main
```
创建一个名为 code-workflow 的分支：
```
git checkout -B code-workflow
```
-b 参数指定如果不存在分支，则创建一个新分支。如果要切换到现有分支，请略去 -b 参数。

默认情况下，新分支基于你运行 git checkout 命令所在的上一个分支。此处的父分支为 main，但是父分支可以是另一个分支，例如由其他人启动的功能分支，而你想要以该分支为基础或试用该分支。

现在可安全地进行所需的任何更改，因为你在自己的本地分支上。如果要查看你所在的分支，请运行 git branch -v。

在文件资源管理器中打开 azure-pipelines.yml，并用以下代码替换其内容：

trigger:
- '*'

pool:
  vmImage: 'ubuntu-20.04'
  demands:
  - npm

variables:
  buildConfiguration: 'Release'
  wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
  dotnetSdkVersion: '6.x'

steps:
- task: UseDotNet@2
  displayName: 'Use .NET SDK $(dotnetSdkVersion)'
  inputs:
    version: '$(dotnetSdkVersion)'

- task: Npm@1
  displayName: 'Run npm install'
  inputs:
    verbose: false

- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
  displayName: 'Compile Sass assets'

- task: gulp@1
  displayName: 'Run gulp tasks'

- script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
  displayName: 'Write build info'
  workingDirectory: $(wwwrootDir)

- task: DotNetCoreCLI@2
  displayName: 'Restore project dependencies'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Build the project - $(buildConfiguration)'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration $(buildConfiguration)'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - $(buildConfiguration)'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
    zipAfterPublish: true

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

此配置与你在之前的模块中创建的基本配置类似。为简洁起见，它只生成项目的发布配置。

将你的分支推送到 GitHub

在这里，将 code-workflow 分支推送到 GitHub 并观察 Azure Pipelines 生成应用程序的过程。

在终端中，运行 git status 来查看分支上存在的未提交的工作：
```
git status
```
你会看到 azure-pipelines.yml 已经修改。你会很快将其提交到你的分支，但是首先需要确保 Git 正在跟踪这个名为“暂存文件”的文件。

仅在运行 git commit 时才会提交暂存的更改。接下来，运行 git add 命令来将 azure-pipelines.yml 添加到临时区域或索引。
运行以下 git add 命令，将 azure-pipelines.yml 添加到临时区域：
```
git add azure-pipelines.yml
```
运行以下 git commit 命令将暂存文件提交到 code-workflow 分支：
```
git commit -m "Add the build configuration"
```
-m 参数指定提交消息。提交消息成为已更改文件历史记录的一部分。它可以帮助审阅者了解更改，并帮助以后的维护人员了解文件在一段时间的变化情况。

提示

句子末尾显示最佳提交消息：“如果应用该提交，你将...”

如果省略 -m 参数，Git 将打开文本编辑器，你可以在其中详细说明更改。当你要指定提交跨越多行的消息时，此选项很有用。第一个空白行之前的文本指定提交标题。
运行此 git push 命令将 code-workflow 分支推送或上传到 GitHub 上的存储库：
```
git push origin code-workflow
```
（可选）在 Azure Pipelines 中转到你的项目，在生成运行时对其进行跟踪。

这种生成被称为“CI 生成”。管道配置使用所谓的触发器来控制哪些分支参与生成过程。在此处，“*”指的是所有分支。
```
trigger:
- '*'
```
稍后，你将了解如何控制管道配置，仅从你需要的分支中进行生成。

你会看到生成成功完成并得到一个包含所生成的 Web 应用程序的工件。

创建拉取请求

在这里，为分支创建一个拉取请求：

在浏览器中，登录到 GitHub。
转到 mslearn-tailspin-spacegame-web 存储库。
在“分支”下拉列表中，选择你的 code-workflow 分支。
若要启动拉取请求，请选择“参与”，然后选择“打开拉取请求”。
确保“基本”指定的是你的分支存储库而不是 Microsoft 存储库。

你的选择如下所示：

重要

这一步很重要，因为无法将更改合并到 Microsoft 存储库中。请确保基本存储库指向的是你的 GitHub 帐户，而不是 MicrosoftDocs。

如果你最终有一个针对 MicrosoftDocs 的拉取请求，只需关闭该拉取请求，再重复这些步骤即可。

此过程还涉及到一个步骤，因为你是从分支存储库中操作的。直接使用自己的存储库而不是分支时，默认情况下会选择 main 分支。
为拉取请求输入标题和说明。
- 标题：
  
  配置 Azure Pipelines
- 说明:
  
  此管道配置会生成应用程序并为发布配置创建一个生成。
若要完成拉取请求，请选择“创建拉取请求”。

此步骤不合并任何代码。它告知其他人你有提议要合并到 main 的更改。

这会显示拉取请求窗口。你可看到 Azure Pipelines 中的生成状态配置为随附拉取请求一起显示。这样，你和其他人就可在生成运行时查看生成的状态。

正如将分支推送到 GitHub 时一样，默认情况下，拉取请求会触发 Microsoft Azure Pipelines 来生成应用程序。

提示

如果没有立即看到显示生成状态，请稍等片刻或刷新页面。
（可选）选择“详细信息”链接，然后在生成通过管道时跟踪生成。

你可以将生成交给流程中的下一步，例如 QA。稍后，你可以配置管道，将更改一直推送到 QA 实验室或生产环境。
回到你在 GitHub 上的拉取请求。

等待生成完成。现在即可合并拉取请求。
选择“合并拉取请求”，然后选择“确认合并”。
若要从 GitHub 中删除 code-workflow 分支，请选择“删除分支”。

合并拉取请求后，从 GitHub 删除分支没有任何风险。事实上，这种做法很常见，因为不再需要该分支。更改合并后，你仍然可以在 GitHub 或命令行中找到有关更改的详细信息。删除合并的分支也可帮助其他人只看到当前正在进行的工作。

Git 分支的生存期较短。合并某分支后，不会向它推送其他提交，也不会再次合并它。在大多数情况下，每次启动新功能或 bug 修补程序时，都是从基于 main 分支且未使用的分支开始操作的。

删除 GitHub 上的分支不会从本地系统中删除该分支。为此，你可以将 -d 开关传递给 git branch 命令。

会生成多少次更改？

答案取决于如何定义你的生成配置。 Azure Pipelines 允许你定义触发器，用于指定导致生成发生的事件。你可以控制生成哪些分支，甚至可以控制哪些文件触发生成。

例如，假设你希望在任何 Git 分支上将更改推送到 GitHub 时进行生成。但是，你不希望在只更改项目的 docs 文件夹中的文件时进行生成。你可能希望在生成配置中加入此 trigger 部分：

trigger:
  branches:
    include:
    - '*'     # build all branches
  paths:
    exclude:
    - docs/*  # exclude the docs folder

默认情况下，在将更改推送到任何分支上的任何文件时都会触发生成。

持续集成 (CI) 生成是在将更改推送到分支时运行的一种生成。

拉取请求 (PR) 生成是在你打开拉取请求或将其他更改推送到现有拉取请求时运行的生成。

通过 code-workflow 分支进行的更改是在下面 3 个条件下生成的：

将更改推送到 code-workflow 分支时会发生 CI 生成。
在 code-workflow 分支上针对 main 分支打开拉取请求时，会发生 PR 生成。
拉取请求合并到 main 分支后，会发生最终的 CI 生成。

PR 生成可帮助你验证所提出的更改在合并到 main 或其他目标分支之后是否将正常工作。

最后的 CI 生成验证了合并 PR 后的更改仍然有效。

（可选）转到 Azure Pipelines，并观察 main 分支上进行最终 CI 生成的情况。

练习 - 创建拉取请求

创建分支并添加起始代码

将你的分支推送到 GitHub

创建拉取请求

会生成多少次更改？

反馈