github实战指南03-Pull Request 全流程实战

03 - Pull Request 全流程实战

本章目标：完整走一遍 PR 的创建、Review、合并全流程，这是企业开发中最高频的操作。

一、PR 的本质

PR 不是"请求合并代码"，而是一次代码评审的协作过程。

复制代码

开发者创建 PR
     │
     ▼
GitHub 自动跑 CI（如果有 Actions）← 必须通过
     │
     ▼
Code Review（人工审核）← 至少 1 人批准
     │
     ▼
合并到目标分支
     │
     ▼
自动部署（如果有 CD）

二、实战：创建你的第一个 PR

2.1 准备工作

bash 复制代码

# 确保你在 main 分支，且代码是最新的
git checkout main
git pull origin main

2.2 创建功能分支

bash 复制代码

# 创建并切换到新分支
git checkout -b feature/add-about-page

# 验证分支
git branch
# 输出：
# * feature/add-about-page
#   main

2.3 开发并提交

bash 复制代码

# 创建 About 页面
cat > about.html << 'EOF'
<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <title>关于我们</title>
    <style>
        body { font-family: Arial, sans-serif; margin: 40px; }
        h1 { color: #333; }
        p { color: #666; line-height: 1.6; }
    </style>
</head>
<body>
    <h1>关于我们</h1>
    <p>这是一个 Git 实战练习项目。</p>
    <p>作者：你的名字</p>
    <a href="index.html">返回首页</a>
</body>
</html>
EOF

# 提交
git add about.html
git commit -m "feat: add about page"

# 推送到远程
git push -u origin feature/add-about-page

2.4 在 GitHub 上创建 PR

复制代码

推送后，GitHub 页面会显示：
"feature/add-about-page had recent pushes - Compare & pull request"

点击这个按钮，进入 PR 创建页面。

PR 创建表单：

复制代码

Title: feat: add about page

Description:
## 改动说明
- 新增 About 页面（about.html）
- 页面包含项目介绍和返回首页链接

## 关联 Issue
- 无

## 测试
- ✅ 本地浏览器测试通过
- ✅ 页面在 Chrome / Firefox 中正常显示

## 截图
[粘贴页面截图]

2.5 审核设置

复制代码

Reviewers：@你的朋友（让他帮你 Review）
Assignees：@自己
Labels：enhancement
Milestone：（如果有就选）
Linked Issues：（如果有就填）

三、PR 的高级操作

3.1 Draft PR（草稿）

复制代码

如果 PR 还没准备好，可以创建 Draft PR：

创建 PR 时点击 "Create draft pull request" 而不是 "Create pull request"

Draft PR 的特点：
- 不能合并
- CI 仍然会运行
- 适合展示进度、寻求早期反馈

3.2 PR 中添加提交

bash 复制代码

# 在 PR 分支上继续开发
git checkout feature/add-about-page

# 修改文件...
git add .
git commit -m "fix: improve about page layout"
git push

# GitHub 会自动更新 PR，不需要重新创建！

3.3 PR 中引用 Issue

markdown 复制代码

# 在 PR 描述中：
Closes #123           # 合并 PR 后自动关闭 Issue
Fixes #123            # 同上
Resolves #123         # 同上

# 在评论中：
See #123              # 链接到 Issue
@username see #123    # 提及某人并引用 Issue

3.4 PR 模板自动填充

bash 复制代码

# 使用 URL 参数自动填充 PR 表单
# https://github.com/owner/repo/pull/new/main?template=bug_report.md

# 在仓库中创建 .github/PULL_REQUEST_TEMPLATE.md
# 之后每次创建 PR 都会自动填充模板

四、Code Review 实战

4.1 作为 Reviewer

bash 复制代码

# 1. 打开 PR 页面
# 2. 点击 "Files changed" 查看代码改动
# 3. 点击具体代码行添加评论

# 评论类型：
# - 普通评论：讨论整体方案
# - 行评论：针对具体代码
# - 建议评论：直接给出修改建议（可以一键应用）

# 示例评论：
"""
这里的变量命名不太清晰。
建议从 data 改为 userData，这样更明确。

建议：
```js
- const data = response.data;
+ const userData = response.data;

"""

复制代码

### 4.2 Review 检查清单

□ 功能是否正确实现了需求？

□ 代码是否可读？

□ 命名是否清晰？

□ 是否有明显 bug？

□ 是否有安全隐患？

□ 是否需要添加测试？

□ commit message 是否规范？

复制代码

### 4.3 作为 PR 作者如何回应 Review

✅ 好的回应：

"已修复，感谢指出！"
"这里我用了 XXX 方案是因为 XXX，你觉得呢？"
"Done"（已经修改了）

❌ 不好的回应：

"这是你理解错了"
不回复任何评论

五、合并 PR 的选项

5.1 三种合并方式

Create a merge commit（创建合并提交）
- 保留完整历史
- 会产生一个 merge commit
- 企业最常用
Squash and merge（压缩合并）
- 把所有 commit 压缩成一个
- 历史最干净
- 适合 feature 分支有很多小 commit 的情况
Rebase and merge（变基合并）
- 线性历史
- 不产生 merge commit
- 历史最干净
5.2 选择建议

小团队、简单项目 → Squash and merge（最干净）

大团队、复杂项目 → Create a merge commit（保留完整历史）

个人项目 → Rebase and merge（线性历史）

复制代码

### 5.3 合并前检查

GitHub 会显示：

☑ All conversations must be resolved（所有讨论必须解决）

☑ Approved（至少 1 人批准）

☑ Tests passed（CI 必须通过）

☑ No conflicts（不能有冲突）

复制代码

---

## 六、删除已合并的分支

```bash
# 合并 PR 后，GitHub 会提示删除分支
# 点击 "Delete branch" 按钮

# 或者手动删除
git checkout main
git pull origin main
git branch -d feature/add-about-page
git push origin --delete feature/add-about-page

七、PR 冲突解决

7.1 冲突场景

复制代码

你创建了 PR，但 main 分支在你开发期间有了新提交
导致你的代码和 main 的代码冲突了

7.2 解决方法

bash 复制代码

# ===== 方法一：在本地解决 =====
git checkout feature/add-about-page
git fetch origin
git rebase origin/main

# 解决冲突...
git add .
git rebase --continue

git push --force-with-lease

# ===== 方法二：在 GitHub 网页上解决 =====
# 点击 "Resolve conflicts" 按钮
# 在线编辑器中解决
# 点击 "Mark as resolved"
# 点击 "Commit merge"

八、PR 最佳实践

8.1 创建 PR 的规范

复制代码

✅ 好的 PR：
- 标题清晰（feat: add about page）
- 描述完整（做了什么、为什么、怎么测试的）
- 关联 Issue
- 小改动（< 400 行）
- 自己先 review 一遍 diff

❌ 不好的 PR：
- 标题是 "update' 或 'fix'
- 没有描述
- 1000+ 行代码
- 混了多个功能

8.2 Review 的规范

复制代码

✅ 好的 Review：
- 给出具体改进建议
- 肯定做得好的地方
- 区分 "必须改" 和 "建议改"
- 及时回复

❌ 不好的 Review：
- 只说 "LGTM"
- 只挑毛病
- 几天不回复

九、实战练习

现在请你在你的 my-git-practice 仓库中完成以下操作：

bash 复制代码

# 1. 创建功能分支
git checkout main
git checkout -b feature/add-index-page

# 2. 创建 index.html
cat > index.html << 'EOF'
<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <title>首页</title>
</head>
<body>
    <h1>我的 Git 实战练习</h1>
    <ul>
        <li><a href="about.html">关于我们</a></li>
    </ul>
</body>
</html>
EOF

# 3. 提交并推送
git add index.html
git commit -m "feat: add index page"
git push -u origin feature/add-index-page

# 4. 在 GitHub 上创建 PR
# 5. 自己给自己写 Review 评论
# 6. 合并 PR
# 7. 删除分支

十、练习清单

创建一个完整的 PR（包含描述和关联 Issue）
自己 Review 自己的 PR（体验 Review 流程）
合并 PR 并删除分支
尝试 Squash and merge
制造一次 PR 冲突并解决
创建一个 Draft PR

上一章 ：02-GitHub仓库管理与Issue

下一章： $04-GitHub Actions自动化实战$ (04-GitHub Actions自动化实战.md)

github实战指南03-Pull Request 全流程实战

03 - Pull Request 全流程实战

一、PR 的本质

二、实战：创建你的第一个 PR

2.1 准备工作

2.2 创建功能分支

2.3 开发并提交

2.4 在 GitHub 上创建 PR

2.5 审核设置

三、PR 的高级操作

3.1 Draft PR（草稿）

3.2 PR 中添加提交

3.3 PR 中引用 Issue

3.4 PR 模板自动填充

四、Code Review 实战

4.1 作为 Reviewer

五、合并 PR 的选项

5.1 三种合并方式

5.2 选择建议

七、PR 冲突解决

7.1 冲突场景

7.2 解决方法

八、PR 最佳实践

8.1 创建 PR 的规范

8.2 Review 的规范

九、实战练习

十、练习清单