什么是拉取请求？

拉取请求 (PR) 是一种向代码库提出修改建议的方法。软件开发者将主代码存储库复刻到一个独立分支，在开发过程中将代码提交到该分支，然后创建拉取请求，以便在将更改拉取或合并到主代码库之前，标记出他们建议的更改供代码评审。

PR 是 Git 存储库（如 Bitbucket 和 GitHub）中常见的机制。GitLab 对同一流程使用了术语“合并请求”而非“拉取请求”。

开发者可以通过命令行界面 (CLI) 或 Web 界面创建拉取请求。新的拉取请求通常用于修复缺陷、更新依赖项、添加新特性或重构代码。拉取请求简化了代码评审，使代码库保持标准，并促进软件开发团队成员之间的协作。

PR 让开发者能够编写源代码并在本地测试。由于代码更改与主分支隔离，开发者无需担心破坏整个代码库。

拉取请求方法涉及三个关键角色，这些角色主要适用于开源项目，但也可被专有或闭源项目采用：

• 维护者：项目维护者管理（并且通常拥有）项目，有权批准并合并 PR 或拒绝它们。

• 评审者：这些团队成员（他们本身可以是维护者，也可以是项目中经验丰富的其他活跃贡献者）对建议的更改进行代码质量评审，并根据需要提出改进建议。

• 贡献者：这些开发者负责进行更改并发起拉取请求。

创建拉取请求通常包含七个步骤：

1. 贡献者复刻主存储库以创建一个新分支（使用 git checkout 命令或 Web 界面），并将此分支克隆到本地计算机。
   
   
2. 贡献者进行更改，并在本地将代码提交到该分支。
   
   
3. 贡献者完成并测试代码后，首先从主存储库拉取最新更新，以避免推送代码时出现任何冲突的更改。
   
   
4. 贡献者为其建议的更改发起一个新的拉取请求，以便将这些更改集成到主分支中。
   
   
5. 评审者在拉取请求提交后会收到通知。他们检查 PR，比较贡献者分支与主分支之间的差异（也称为 diff），评审代码并对需要优化或改进的地方发表评论。
   
   
6. 贡献者根据评审者的建议和修改要求进行额外的代码提交。
   
   
7. 当所有修改完成后，评审者通知维护者，由维护者批准该 PR。然后拉取请求被合并到主存储库中。

软件开发团队可以根据需求选择多种 PR 工作流选项。常见的拉取请求工作流包括：

• 特性分支工作流

• 复刻工作流

• git-flow

• 堆叠工作流

每个新特性都有自己专用的分支，并使用描述性名称来突出该特性的目的。特性完成后，开发者可以将特性分支推送到主分支并创建拉取请求。

该工作流在贡献者独立开发各个特性时保持了主分支的稳定性，但管理多个特性分支可能会变得笨拙。

上一节关于创建拉取请求中概述的七步流程对应的是复刻工作流。开源项目通常采用此工作流，它也与持续集成/持续交付 (CI/CD) 实践相辅相成。GitHub 流程 遵循与复刻工作流类似的过程。

软件工程师 Vincent Driessen 于 2010 年制定了 git-flow。它通常用于具有严格发布计划或需要支持多个版本的软件开发。

此工作流遵循由以下分支组成的分支模型：

• main 保存最新的稳定版本

• develop 作为集成分支，用于修复缺陷、添加特性以及下一个版本中包含的其他代码更改

• feature 使用 develop 作为源分支和目标分支，feature 准备好后合并到 develop

• release 从 develop 复刻出来，并标记下一个版本的版本号，在适合发布时同时合并到 develop 和 main

• hotfix 直接从 main 复刻，用于修复任何高优先级或高严重性的生产问题，修复完成后立即合并到 develop 和 main

开发者需要对需要评审的 hotfix 、feature 和 release 分支创建拉取请求。

堆叠工作流将大型任务分解为一系列小型、增量的代码更改。下一个代码更改依赖于前一个，因此拉取请求是相互堆叠构建的。

考虑一个涉及以下功能更改的特性：数据库或数据模型、API 和前端。在传统的特性分支或复刻工作流中，贡献者必须等待数据库或数据模型更改的 PR 经过评审、批准并合并到主分支后，才能开始进行 API 更新。在堆叠工作流中，这个等待期被消除了——贡献者可以从数据库或数据模型更改分出分支来开始 API 的工作，为 API 提交 PR，再从 API 更改分出分支来处理前端任务。

拉取请求具有以下优势：

• 培养协作

• 提高代码质量

• 增加透明度

• 强化编码技能

拉取请求促进合作，鼓励团队成员无论其角色如何都能一起工作。PR 有助于提供反馈并学习如何处理反馈，激发讨论并引发改进的思路。

PR 启动代码评审过程，帮助发现缺陷、偏离编码风格和规范的地方、性能问题以及安全漏洞。这种额外的监督能够维持甚至提升代码质量。

拉取请求让团队能够看到实现了哪些更改、由谁实现、应用在何处以及背后的原因。这种可见性使团队更好地了解代码库以及项目本身的状态。

评审者和贡献者都可以互相学习，在此过程中掌握新技术，发现解决问题的新方法。新手和新团队成员也可以研究以往的 PR，从而更好地理解代码库，并快速掌握团队的编码标准和最佳实践。

虽然创建拉取请求看起来很简单，但以下一些技巧可以进一步使流程更顺畅：

• 考虑草稿

• 细节决定成败

• 保持专注

• 关注最新动态

• 使用模板

草稿拉取请求（或合并请求）为开发者提供了一种分享进行中工作的途径。这使得团队成员能够更早开始协作并更早获得反馈，从而让遇到问题的开发者可以从队友那里集思广益，找到可能的解决方案。

开发者必须为其新提交提供清晰、简洁且具体的消息。清晰、简洁和具体也同样适用于 PR 的标题和描述，使评审者能够更快、更轻松地理解代码更改背后的意图。

将多个问题捆绑到单个 PR 中会导致更长的评审时间和更多的修订。每个拉取请求应只针对一个缺陷修复或一个特性。有针对性的拉取请求能够带来更高效的代码评审。

在推送代码并发起 PR 之前，开发者必须确保其分支是最新的。拉取最新的更改和任何新提交可以避免合并拉取请求时出现冲突。他们可以使用 git pull 命令从目标分支获取并合并更改，或者使用 git rebase 命令获得干净的 git 提交历史。

PR 描述模板有助于确保一致性，并提供重要的上下文，从而简化代码评审。团队可以为不同类型的拉取请求（如缺陷修复、特性或重构代码）制作模板。

模板通常使用 Markdown 标记语言编写，并放置在项目存储库的根文件夹或主分支中。典型的字段包括：

• 问题或特性描述（附上 Jira 或其他问题跟踪软件中对应票据的链接以供参考）

• 详细说明代码更改的解决方案

• 测试，例如单元测试或集成测试用例、测试覆盖率以及适用的手动验证步骤

• 配置变更

• 相关任务的检查清单，例如代码文档、无错误或无警告的干净代码构建

自动化 PR 可以加快拉取请求从创建、评审到合并的生命周期。PR 自动化包含一层有助于缓解瓶颈的系统：

• 堆叠 PR

• CI/CD 流水线

• 软件开发生命周期 (SDLC) 管理系统

• 人工智能驱动编码助手

大多数 Git 存储库并非为支持堆叠工作流而设计，但有些工具抽象掉了同步堆叠拉取请求和处理合并冲突的复杂性。这些工具包括 Graphite  平台（其提供了用于堆叠 PR 的 CLI 和用于 Microsoft VS Code 的扩展，以及用于管理这些 PR 的 Web 界面）、Meta 的 Sapling  源代码管理系统，以及开源的 ghstack  CLI（用于将堆叠差异作为独立的拉取请求提交到 GitHub）。

作为自动化的 DevOps 工作流，CI/CD 流水线有助于确保代码质量。GitHub Actions、GitLab 等平台以及其他 CI 工具可以运行单元测试和集成测试，并部署预览环境，这些环境充当沙箱，用于在 PR 中查看和测试代码更改。

CI/CD 流水线也强化了安全编码实践。静态代码分析器和其他静态应用安全测试 (SAST) 工具可以与大多数 CI/CD 环境无缝集成，以精确定位可能的代码漏洞。DevOps 团队可以实现用于机密检测的预提交钩子，使机密扫描成为开发者提交代码或发起拉取请求之前的必要步骤，并阻止包含硬编码机密的更改。

像 Jira 和 IBM Engineering Lifecycle Management (ELM) 这样的平台支持在整个软件开发生命周期 (SDLC) 中跟踪和管理拉取请求。

作为 ELM 套件的一部分，IBM Engineering Workflow Management (EWM) 和 IBM Engineering Integration Hub 将 PR 自动化直接嵌入到开发工作流中。EWM 可以通过 Hub 的连接器与 Git 存储库连接，并从工作项触发 PR 创建。当 EWM 中的需求或变更请求被批准后，一条规则可以自动在关联的 Git 存储库中打开一个拉取请求，并预填充描述。

ELM 中由 AI 驱动的自动化也可以在 PR 打开后运行静态分析和测试套件，将结果发布回工作项，并阻止合并直到满足条件。同时，Hub 会跨工具同步 PR 状态，在存储库和 EWM 仪表板中实时反映该状态。

像 GitHub Copilot 和 IBM Bob 这样人工智能驱动的编码助手可以增强拉取请求工作流。例如，Bob 可以生成格式良好、有意义的提交消息。它会检查分支名称和提交历史，以匹配项目的风格规范。

Bob 还可以直接从开发者的 IDE 中创建拉取请求。它会分析分支名称、代码更改和提交历史，以理解目的和范围。然后生成 PR 标题和详细描述，总结所做的更改，并自动检测和使用项目现有的 PR 模板来生成拉取请求描述。