4.3 團隊協作核心：Pull Request (PR)#
為什麼需要 PR？#
直接 push 到 main 的問題：沒有人審核你的程式碼，壞東西就上線了。
Pull Request（PR） 的精神：把你的分支「提出來」，讓隊友看過、討論過、通過審核後才合併進 main。這是現代團隊協作的品質關卡。
兩種協作模式#
| 模式 A：共同儲存庫 | 模式 B：Fork + PR | |
|---|---|---|
| 適用 | 團隊內部（同事） | 開源專案（陌生人） |
| 方式 | 直接在同一個 repo 開分支 | 先複製到自己帳號下，再發 PR 回原專案 |
| 權限 | 需要寫入權限 | 不需要寫入權限 |
模式 A：團隊內部 PR 流程#
git switch -c feature/login
# ...寫程式、commit...
git push -u origin feature/login
然後在 GitHub 網頁上：
- 進入儲存庫，點 Pull requests → New pull request
- 選擇要合併的分支（
base: main←compare: feature/login） - 寫清楚這個 PR 做了什麼、為什麼、如何測試
- 提交 PR，等待隊友審核
模式 B：Fork 開源專案並發起 PR#
- 在原專案頁面按右上角 Fork，複製到自己帳號下
- Clone 你 fork 出來的版本：
git clone git@github.com:你的帳號/some-project.git
- 建立分支、修改、commit、push 到你的 fork
- 在 GitHub 上從你的 fork 向原專案發起 PR
Code Review 與審核合併#
審核者在 PR 頁面上可以：
- 看 diff：逐行檢視變更
- 留言：在特定行上提問或建議（Request changes）
- 批准：Approve 這個 PR
常見的團隊規則：
- 至少一位隊友 approve 才能合併
- CI 測試全部通過才能合併（見 GitHub Actions）
- 合併後刪除功能分支，保持整潔
PR 的範圍越小越好審。一個改 50 行的 PR 會被認真看，改 3000 行的 PR 只會被無腦 approve。