Pull Request：什么是PR、创建流程和代码审查

什么是Pull Request？

Pull Request (PR) — 是在分布式版本控制系统中将一个分支的更改正式请求合并到另一个分支。PR是GitHub、GitLab和Bitbucket平台上协作开发的核心元素，结合了代码讨论、自动化测试和更改审批流程。

名称 “Pull Request” 反映了操作的本质：开发者请求仓库所有者“拉取”(pull)他的更改。该术语由GitHub于2008年引入 — 在此之前，类似机制以补丁(patch)和merge request（GitLab术语）的形式存在。如今，PR是基于Git的团队开发的事实标准。

根据 GitHub Octoverse, 2025 数据，89%的开源项目要求创建PR才能提交更改。在企业开发中，这一指标达到95%。PR不仅是技术工具，更是开发文化的一部分：通过PR进行知识传递、发现错误和协商架构决策。

Pull Request的组成部分

典型的PR 包含标题、描述、更改文件列表(diff)、审查者评论和CI检查状态。每个PR关联到特定的源分支和目标分支，合并后可以自动删除。

如何创建Pull Request

创建PR 始于将feature分支发布到远程仓库。推送后，开发者通过平台界面或CLI(gh, glab)打开PR。下面以GitHub为例说明流程。

推送分支并打开PR

第一步 — 将feature分支推送到远程仓库，并通过Web界面或命令行创建Pull Request。

# 创建并推送feature分支
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# 通过GitHub CLI创建PR
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

创建PR后，GitHub会自动运行CI流水线(GitHub Actions)，检查与目标分支的冲突，并邀请审查者。PR描述模板可以通过.github/PULL_REQUEST_TEMPLATE.md进行配置，使所有PR都包含必要部分：目的、更改、测试、相关任务。

描述和标签

高质量的PR描述 包括：任务链接(issue/ticket)、更改简要说明、测试指南和相关更改列表。标签(bug、feature、refactoring)有助于对PR进行分类，而assignees和reviewers通过CODEOWNERS自动分配。

# 通过CODEOWNERS分配审查者（位于仓库根目录的文件）
# 示例 .github/CODEOWNERS：
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# 通过gh cli创建带有审查者分配的PR
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS — 是GitHub/GitLab的标准机制，根据更改的文件自动分配审查者。例如，src/auth/目录中的任何更改会自动将team-auth和senior-dev指定为审查者。这加速了流程并确保合适的人员看到PR。

根据审查更新PR

收到审查者的评论后，开发者在同一个feature分支中进行修正并推送新的提交 — PR会自动更新。重要的是不要在已发布的feature分支上重写历史(rebase)（如果PR已打开），因为这会破坏评论中对特定提交的链接。

# 根据审查者评论进行更改
git checkout feature/biometric-auth
# 修复代码
git commit -m "fix: handle biometric timeout per review"
git push

# PR将自动更新
# 批准后——通过GitHub界面合并PR

代码审查流程

代码审查 — 是Pull Request的核心要素。审查者检查更改的正确性、代码风格、安全性和架构一致性。高质量的审查不仅能防止错误，还能在团队内传播关于代码库的知识。

Google的Engineering Practices（2025年）推荐以下代码审查原则：审查者必须理解更改的上下文，提供具体建议而非一般性意见，并区分技术性和风格性评论。审查时间不应超过PR创建后的24小时。

对于移动开发，代码审查包括特定检查：与targetSdk的兼容性、生命周期(Android)/view生命周期(iOS)的正确处理、无内存泄漏(LeakCanary, Instruments)、暗黑模式支持和本地化。这些检查可以通过linter和Detekt/ktlint自动化。

评论类型

PR平台支持三种评论类型：总体评论（针对整个PR）、行内评论（针对特定代码行）和建议(suggestions，附带替换代码)。suggestions允许一键应用更改，加速流程并减少迭代次数。

在所有评论都解决且CI检查通过后，审查者发送批准(Approved)。PR可以合并。GitHub和GitLab支持分支保护规则：必须的批准数量、必须的CI检查、禁止无PR直接推送到main。对于移动项目，分支保护还包括构建检查：如果应用程序无法编译(gradle build failed / xcodebuild failed)，则不能合并PR。

PR中的冲突解决

合并冲突在Pull Request中是团队活跃合作时的常见情况。平台通过Web界面提供冲突解决（针对简单冲突）或建议本地解决。GitHub Actions在每次推送到feature分支时自动检查可合并性，如果无法合并则将PR标记为冲突。

Pull Request最佳实践

高效的Pull Request能加速代码审查并减少错误数量。SmartBear（2025年）的研究表明，大小在200行代码以内的PR获得的有意义评论数量是超过1000行PR的2倍，而审查时间缩短了3倍。

• 小型PR — 最佳大小为100-300行。将大型PR拆分为逻辑部分：每个PR解决一个任务。这简化了审查并降低了冲突的可能性
• 清晰的描述 — 标题遵循Conventional Commits（feat:、fix:、refactor:），PR正文包含“什么和为什么”，而非“如何”（代码本身会说明）。模板：目的 → 更改 → 测试 → 相关任务
• 快速反馈 — 24小时内进行审查。如果PR等待超过一天，团队会失去上下文，合并时冲突数量增加
• 自动化 — linter、formatter和测试应在创建PR时自动运行。不允许合并CI检查失败的PR
• Draft PR — 用于早期架构讨论。Draft PR不需要审查且不能合并，但允许在早期阶段向同事展示代码

其他实践：不要在周五晚上创建PR（没人会在周一前审查），向1-2人请求审查（更多人会降低流程速度而不提高质量），使用squash merge在合并前压缩历史。对于移动项目，还建议在PR描述中添加测试构建链接（Firebase App Distribution / TestFlight），以便审查者能在运行的应用程序中检查更改。

不同平台上的Pull Request

处理Pull Request的主要平台有GitHub、GitLab和Bitbucket。尽管概念相同，但每个平台都有其特点，在选择团队工具时应予以考虑。

GitHub — 最受欢迎的平台，拥有最大的社区、用于CI/CD的Actions和广泛的应用生态系统(GitHub Marketplace)。GitLab以内置CI/CD和完全自托管部署能力著称。Bitbucket与Jira和Atlassian生态系统紧密集成，在企业环境中很受欢迎。

对于移动开发，平台的选择通常取决于CI/CD能力：GitHub Actions支持用于iOS构建的macOS runner，GitLab有用于iOS/Android的内置runner，Bitbucket与Firebase Test Lab良好集成。无论平台如何，PR流程保持不变：分支 → 审查 → CI → 合并。