Pull Request

这一课你将能做到

1. 写出让审查者乐意合并的 PR 描述（标题+动机+改动点+测试方式+截图）
2. 在 GitHub PR 页面审查他人代码，会提具体评论、请求修改、最终批准
3. 处理 PR 中的 review 反馈：本地修改后更新同个 PR，以及正确解决合并冲突

为什么要学

PR 不只是「请求合并」，它是现代团队的质量门禁——设计评审、代码审查、CI 检查、自动化测试，全部发生在 PR 阶段。一个写得好的 PR 能让审查者 30 秒看懂你在干嘛；一个写得烂的 PR，审查者直接跳过、bug 溜进生产环境。

对初学者来说，PR 也是最佳学习窗口：你的代码会被更有经验的人逐行点评，进步速度比闷头写快十倍。

先建立图像

PR 的生命周期：

1. 推送功能分支                    2. 创建 PR
3. CI 自动跑测试                   4. 审查者审阅
5. 修正反馈（可能多轮）             6. 合并进 main

分支: feature/xxx ──────────────────> PR ──────────────────> main
        │                                                    │
        │         commit 1 ← 修正 ← 审查者评论                │
        │         commit 2                                      │
        │         commit 3                                      │
        └───────────────────────────────────────────────────────┘

跟着做

步骤 1：推送功能分支

git switch -c fix/login-redirect
git add . && git commit -m "fix(auth): 登录后重定向到正确页面"
git push -u origin fix/login-redirect

步骤 2：创建 PR

在 GitHub 页面点「Compare & pull request」，按以下模板填写：

## 改动动机
修复 #42：用户登录后跳转到了 404 页面。

## 做了什么
- 在 LoginService.java 第 58 行把默认重定向 URL 从 `/home` 改为 `/dashboard`
- 补充了重定向的单元测试

## 怎么验证
1. 运行 `mvn test`
2. 本地启动，访问 `/login` 用 test/test 登录
3. 确认跳转到 `/dashboard`

## 截图（如有 UI 改动）
[此处贴截图]

## 涉及 Issue
Closes #42

Closes #42 是 GitHub 魔法关键词，PR 合并后会自动关闭对应 Issue。

步骤 3：审查别人 PR

在 PR 页面切换到「Files changed」标签：

• 点某行左侧的 + 号添加评论
• 提出具体意见：第 34 行应该用 Optional.ofNullable 避免空指针
• 提完意见点「Request changes」让对方修改
• 全部满意后点「Approve」

步骤 4：收到审查意见后修改

git switch fix/login-redirect
# 按审查意见改代码...
git add .
git commit -m "fix: 改用 Optional 处理空指针（review 反馈）"
git push                          # 自动追加到原 PR

不需要重新开 PR，push 后原 PR 会自动更新。

步骤 5：解决合并冲突

如果 PR 提示「This branch has conflicts」：

git switch fix/login-redirect
git merge main                    # 把最新 main 合进来
# Git 会在冲突文件里标记 <<<<<<< HEAD ======= >>>>>>> main
# 手动打开文件，选择保留的版本，删掉冲突标记
git add 冲突文件
git commit                        # 提交合并
git push                          # PR 自动更新