Pull Request / PR

請團隊檢查並合併一組程式碼修改的流程。

先用一句話理解

請團隊檢查並合併一組程式碼修改的流程。

打個比方

像交作業前請同事審稿，再正式交出去。

什麼時候會遇到

多人協作、需要 code review、或部署前想保留紀錄時。

再往深一點看

Pull Request 是你在 GitHub 上發起的一個請求，意思是「我這條 branch 上的修改準備好了，請大家審查，沒問題的話合併進 main」。PR 不只是合併工具，它也是整個討論與把關的空間——reviewer 可以在特定程式碼行留評論、要求修改、跑 CI 自動測試，通過後才按下 merge。PR 的描述裡應該說明這次改了什麼、為什麼改、如何測試，讓 reviewer 快速理解背景，而不是直接丟一堆 commit 讓別人猜。Vercel 等平台還會在每個 PR 上產生獨立的 preview 網址，讓你在正式合併前就能看到實際畫面。

舉個例子

你開發完付款整合功能，在 GitHub 上開 PR，描述裡列出「新增 Stripe checkout 流程、修改訂單 API」，並附上測試步驟。技術主管在 PR 留言「這行要處理付款失敗的錯誤」，你修正後再 push，CI 測試通過、主管 approve，才按下 merge 把程式碼合進 main。

常見誤解

- PR 描述只寫「新增功能」或留白，reviewer 不知道改了什麼、要測哪些情境，只好逐行自己猜，審查效率很差。
- 一個 PR 塞了好幾個不相關的功能，reviewer 要花很長時間才能看完，也很難判斷每個改動的風險。
- 把 PR 視為純形式，approve 後就立刻 merge，沒有等 CI 跑完或 preview 環境驗證，直接把錯誤帶進正式版本。