如何进行拉取请求评审

TLDR

在团队协作时，制定一个流程（哪怕只是一个简单的流程）来创建、审查和合并所有代码库的 PR（拉取请求）是必要的。这使得软件开发流程更加高效，因为所有团队成员都知道将代码推送到生产环境的要求，并且他们可以有效地协作以实现目标。

大纲

• 代码库托管服务

• 分枝

• 创建 PR

• 审查 PR

• 合并 PR

代码库托管服务

Github 与 Bitbucket

Github和Bitbucket是托管团队代码库的两大热门服务。您可以查看Github 和 Bitbucket 的功能和价格，看看哪个更适合您的团队。如果您的团队已经深耕Atlassian生态系统（例如，使用Jira作为项目管理软件，使用Confluence作为文档管理软件），那么使用 Bitbucket 也是明智之举，因为它与 Jira 集成良好。

我们在 Mage 使用什么

我们使用 Github 托管我们的代码库。它无疑是开发者最常用的托管服务，而且新团队成员很容易上手，因为他们可能已经很熟悉它了。Github 团队版定价方案对于少于 10 名开发者的团队来说已经足够了。

分枝

• Mage 的分支命名约定（不带括号）[initials_or_team_name]--[your_branch_title_snake_case]：。

• 在提交消息前加上括号中的您的姓名首字母：[initials]。
  

$ git checkout -b [initials_or_team_name]--[your_branch_title_snake_case]
$ git checkout -b jk--new_sign_up_flow
< make some code changes >
$ git add .
$ git commit -m '[initials] <title of your changes>'

创建 PR

以下是团队成员创建新 PR 的要求：

• 添加至少一名审阅者（Github 的免费套餐可能不允许添加多名审阅者）。

• 将您自己和其他参与 PR 的人员指定为受让人。

• 简要概述所做的工作。可以是要点。

• 如果适用，请包含新功能的屏幕截图（例如，在前端的 UI 上添加功能）。

• 如果适用，请包含示例 API 请求负载。这样审核人员可以更轻松地检查负载是否正确。

• 提及任何添加或执行的测试。

• 在 PR 标题前加上您的姓名首字母缩写（例如[jk]），以便在当前分支合并后，这些首字母缩写会出现在主分支提交历史记录中的提交消息中。

审查 PR

审阅者会仔细检查所有更改，并根据需要提出任何意见。此外，可能还会有一些非阻塞性意见（例如，不需要任何修复的小意见），受让人应该注意到这些意见，但无需采取进一步行动。然后，受让人会处理所有意见，并告知审阅者该 PR 已准备好进行后续审阅。一旦 PR 准备好合并到分支main，审阅者就会批准该 PR。

合并 PR

合并 PR 之前，需要获得审阅者的批准。Github 可以配置为，未经审阅者批准，受让人无法实际合并 PR（合并按钮将被禁用）。

在将 PR 合并到主分支之前，应该确保与主分支不存在任何冲突，并且CI/CD 流水线中的所有测试都应该在当前分支上通过。我们已经撰写了一篇单独的博客文章，介绍如何设置 CI/CD 流水线。

Github 中有三种合并分支的方法：

1. --no-ff 合并提交——当前分支的所有提交都添加到基础分支，并使用选项合并 PR 。

2. 压缩并合并 — PR 的提交被压缩为单个提交，并使用快进选项将 PR 合并到基础分支中。

3. 变基和合并 — 当前分支的所有提交都单独添加到基础分支上，并使用快进选项合并 PR 。

我们使用“压缩并合并”方法将当前分支合并到新分支。您可以在 Github 仓库设置main中配置此功能。我们更喜欢压缩提交，因为它可以让分支的提交历史记录更清晰、更易于阅读。main

当前分支合并到 后main，删除当前分支。这可以在Github中自动完成。