單元 4 · Pull Request 協作

把分支變成審查流程 — Pull Request

← 單元教學

直接把分支 merge 進 main 很危險。GitHub 的答案是 Pull Request（PR）： 一個「請求把某分支合併進另一分支」的審查流程。

PR 是什麼 · What is a PR

PR 流程 · WORKFLOW
1. 開分支 → 開發 → push
2. 在 GitHub 開 Pull Request
   （feature 分支 → main）
3. 隊友 Review：討論、留言、改進
4. 通過檢查 → 合併 Merge
5. 完成！功能進入 main
核心價值：PR 讓「合併程式碼」變成「有記錄、有審查、可回顧」的過程—— 每次合併都有討論串、每行程式碼都能被檢視。

如何開一個 PR

  1. 確認你的分支已 git push 到 GitHub。
  2. repo 頁會出現綠色「Compare & pull request」按鈕。
  3. 確認 base（要合進哪）與 compare（你的分支）。
  4. 寫標題與描述，按 Create pull request。
PR 描述建議：「改了什麼」＋「為什麼改」＋「怎麼測試」—— 讓 reviewer 不用猜。也可用 Markdown 排版（複習我們的 GFM 單元）。

Code Review · 程式碼審查

Reviewer 在 PR 的「Files changed」分頁逐行檢視與留言：

審查動詞意義
Comment一般留言，不阻擋合併
Request changes需要修正後再合併（擋）
Approve同意合併
被 review 的心態：Review 是「一起把程式寫好」，不是批評。 提問式建議（「這裡是不是該考慮…？」）比命令式更受歡迎。

關聯 Issue · Linking Issues

在 PR 描述寫 Closes #12，合併時 GitHub 會自動關閉 issue 12。

PR 描述 · DESCRIPTION
修正登入頁空白問題。

- 加上欄位驗證
- 修正錯誤訊息

Closes #12

關鍵字：fixes、closes、resolves，後面接 #issue編號。

保護分支 · Protected Branches

防止有人直接 push main，強制「必須 PR + review 才能合併」。

設定位置 · SETTINGS
Repo → Settings → Branches → Branch protection rules
├── Require a pull request before merging
├── Require approvals（至少 1 人 Approve）
└── Require status checks（CI 通過才合併，見單元 7）
為什麼重要：沒有保護分支，任何人都能直接動 main—— 一個誤 push 就能讓整條主線壞掉。正式專案必開保護。

三種合併方式

方式效果何時用
Merge commit保留所有 commit 與「合併事件」保留完整歷史
Squash and merge把整條分支壓成一個 commit功能分支（最常見）
Rebase and merge線性重放，無合併事件想保持線性歷史
看完這頁你應該能說出：
  • PR 的完整流程與價值。
  • 如何開 PR、Review 的三種回饋。
  • 用 Closes #12 關聯 issue。
  • 保護分支設定與為什麼重要。
  • 三種合併方式的差別。

延伸閱讀

← 上一篇
單元 3 · 分支與合併
下一篇 →
單元 5 · Issues 與專案管理