💡 前言

昨天我們學會在本地端透過 Git Branch 建立獨立沙盒環境，並順利化解了合併衝突。然而，在真實的團隊開發中，程式碼不能隨便就直接合併回主幹（main），而是必須透過 Pull Request (PR) 機制，經過團隊成員的審查與討論後才能正式上線。

今天 Day 16 我們就來深入探討現代軟體開發的核心協作流程——GitHub Pull Request 與 Code Review！

🎯 本篇重點

1. 什麼是 Pull Request (PR)？為什麼它如此重要？
2. 在 GitHub 上建立與發起 PR 的完整步驟
3. Code Review（程式碼審查）的核心精神與常見注意事項
4. 審查通過後的合併策略（Squash & Merge 概念）

🌉 1. 什麼是 Pull Request (PR)？

Pull Request（在 GitLab 稱為 Merge Request）顧名思義就是「請求合併」。
當你在自己的功能分支（例如 feature/login）開發完畢並 Push 到遠端 GitHub 倉庫後，透過 PR 介面：
• 它提供了一個視覺化的討論區，讓團隊成員可以針對你的程式碼改動進行留言、提問或提出優化建議。
• 它是品質控管的最後一道防線，確保每一行進入主分支的程式碼都符合團隊標準且經過檢視。

🛠️ 2. 如何在 GitHub 上開立 PR

當你把本地分支 Push 到遠端後，通常會經歷以下步驟：

1. 發起提示：打開 GitHub 專案頁面時，通常會看到一個黃色橫幅寫著：「Your recently pushed branches... Compare & pull request」，點擊它。
2. 填寫 PR 資訊：
   • Title（標題）：清楚描述這次變更的目的（例如：feat: 新增會員登入與 Token 驗證機制）。
   • Description（描述）：條列說明這次修改了哪些功能、解決了什麼 Issue、或是需要特別注意測試的地方。
3. 指派審查者 (Reviewers)：在右側選單的 Reviewers 欄位中，點擊並指派專案的資深工程師或協作者來幫你檢查程式碼。
4. 送出 PR：點擊綠色的 Create pull request 按鈕就大功告成！

👀 3. Code Review（程式碼審查）的藝術

身為 Reviewer（審查者） 與 Author（提交者），雙方在 Code Review 過程中扮演著互補的角色：

• 對審查者而言：
不只要挑出有沒有 Bug，更要關注程式碼的可讀性、效能與架構是否符合團隊規範。留言時應保持建設性語氣（例如：「這裡如果改用 async/await 會不會更好讀呢？」而不是「這裡寫得很爛」）。
• 對提交者而言：
把 Code Review 當成學習與成長的絕佳機會。虛心接受修改建議，並針對疑問進行理性溝通。

🔀 4. 合併策略：Squash and Merge

當 PR 獲得 Reviewer 批准且所有 CI/CD 自動化測試都通過後，就可以準備合併回主分支了。GitHub 提供了三種合併選項，其中最推薦的是 Squash and merge（壓縮合併）：
• 特色：它會把你開發過程中所有零散的 Commit（例如：「fix typo」、「test」、「fix again」）全部壓縮成乾淨俐落的 單一個 Commit 再併入主分支。
• 好處：主分支的 Commit History 歷史紀錄會非常乾淨，日後如果要追溯某個功能是在哪一天上線的，可以一目了然！