6. Pull Request (PR) 與 Code Review

在前面的實戰中，都是自己一個人說了算，改完程式碼就直接 merge、直接 push 進 main 分支。但你可以想像一下，如果是在一個有 20 人的開發團隊裡，每個人都這樣自由地把程式碼往 main 分支推，那主線網站大概天天都在爆炸、天天都在解衝突。

為了保護主線程式碼的品質，業界有一套神聖的規範，而這個規範的核心，就叫做 PR（在 GitHub 叫 Pull Request，在 GitLab 則叫 Merge Request，簡稱 MR）。

很多新手第一次聽到 Pull Request 時會非常困惑：「為什麼字面上的意思是『請求別人拉取』？我明明是想把我的程式碼『推』上去合併啊！」

其實，它的邏輯是這樣的：

當你寫好了一個新功能分支（例如 feature/cart），你希望把這段扣合併進專案的官方主線（main）。但你沒有權限直接合進去，所以你發出一個通知，「請求」這座倉庫的管理者（資深工程師或主管）：「嘿！我寫好購物車了，你可以把我的分支『拉（Pull）』進去主線合併嗎？」

這就是 Pull Request 的由來。(但我覺得Gitlab的Merge Request比較直觀理解)

1. 為什麼團隊開發一定要用 PR？

在公司的真實開發流程中，PR 扮演了「海關審查」的角色。它的好處多到數不完：

  • 程式碼審查（Code Review）： 主管或同事會在線上逐行閱讀你寫的程式碼，幫你看看有沒有潛在的 Bug、效能有沒有優化空間、或是寫作風格合不合規範。
  • 防止主線崩潰： 確保每一行進到 main 分支的程式碼，都是經過至少一個人以上檢查過、且測試通過的。
  • 團隊技術交流： 透過 Code Review，資深工程師可以傳授心法給新人，新人也能藉由看別人的 PR 快速學習專案架構。

2. PR 的完整生命週期圖解

我們來看看一個功能從開發到透過 PR 合併的標準流程：

sequenceDiagram
    autonumber
    actor Engineer as 工程師 (你)
    participant GitHub as GitHub 雲端倉庫
    actor Reviewer as 資深工程師 (審查者)

    Engineer->>GitHub: Push 新功能分支 (feature/cart)
    Engineer->>GitHub: 在網頁上建立 Pull Request (PR)
    GitHub->>Reviewer: 通知有新的 PR 待審查
    Note over Reviewer, Engineer: 進入 Code Review 階段
    Reviewer->>Engineer: 「這行程式碼有邏輯漏洞，請修改」
    Engineer->>GitHub: 修改後再次 Push 修正
    Reviewer->>GitHub: 檢查通過，按下一鍵合併 (Merge)
    Note over GitHub: feature/cart 正式合進 main 分支！

3. 實戰!

現在，我們來模擬一次在公司上班的日常：

Step 1：在本地寫好功能並推上分支

我們開一個分支，隨便改動一點東西並推上去（複習一下第四章）：

git checkout -b feature/login
echo "Login logic..." > login.js

git add .
git commit -m "feat: implement basic login function"

# 重點：把這個分支推上雲端
git push origin feature/login
Code language: PHP (php)

Step 2：前往 GitHub 觸發神奇按鈕

當你打開該專案的 GitHub 網頁時，你會看到上方跳出一個醒目的黃色提示條：

feature/login had recent pushes less than a minute ago.

旁邊附帶一個綠色的按鈕：Compare & pull request。不要猶豫，按下去！

Step 3：填寫 PR 履歷表

接下來會進入 PR 的建立頁面，你需要填寫以下資訊：

  1. Title（標題）： 簡短說明這個 PR 做了什麼（例如：feat: 新增使用者登入功能）。
  2. Description（內容描述）： 詳細說明你改了哪些地方、有沒有需要特別注意的設定。在公司裡通常會有固定的模板（Template）。
  3. Reviewers（審查者）： 在右側欄位勾選你想請哪位同事來幫你檢查程式碼。

填寫完畢後往下滑，可以看到自己做的修改，確認都沒問題後，點擊 Create pull request。

4. Code Review 現場：當你被留言指教時怎麼辦？

PR 建立後，你的同事（Reviewer）就會收到通知。他們會點進 Files changed 分頁，開始逐行看你的程式碼。

如果他們發現第 10 行寫得不好，他們可以直接在該行程式碼下方留言：

「這邊用迴圈跑效率太慢了，建議改成 Array.map() 喔！」

🚨 新手最常犯的觀念錯誤：

看到留言後，千萬不要去把這個 PR 關掉（Close），更不需要重新開一個新分支！

你只需要在同一個本地分支（feature/login）上修改程式碼，然後再次 Commit 與 Push：

Bash

# 在本地改好檔案後
git add .
git commit -m "refactor: optimize loop with array map"
git push origin feature/login
Code language: PHP (php)

當你一 Push，GitHub 就會非常聰明地自動把最新的修改更新進同一個 PR 頁面裡。你可以留言回覆同事：「改好囉，請再幫我看看！」

當同事確認沒問題後，他就會幫你點選 Approve（批准），這時你（或主管）就可以高興地按下那顆大大的綠色 Merge pull request 按鈕，你的成果就正式進主線啦！

小結

在現代軟體開發中，「不會發 PR，就等於不會團隊協作」。

  • PR (Pull Request) 是請求管理員將你的分支合併進主線的機制。
  • Code Review 是在 PR 合併前，團隊互相挑錯、優化程式碼的神聖過程。
  • 修改審查意見時，只要持續在同分支 Push 即可，PR 會自動更新。

下一章，我們要來聊聊當團隊變大、功能變多時，大家的分支該怎麼命名？什麼時候該開什麼分支？這就是大廠面試必問的專業規範——Git Flow（分支管理策略）！