合併請求（Pull Request，簡稱 PR）

提交程式變更的協作流程

情境說明

當完成某個功能或修復錯誤後，開發流程通常如下：

  • 在一個分支（例如 feature/xxx 或 bugfix/xxx）上進行開發；
  • 將該分支推送到 GitHub 上的遠端倉庫；
  • 建立一個 Pull Request，通知其他開發者：「這個分支的變更準備合併到主分支（例如 main 或 master）！」

補充說明：
雖然名稱是「Pull Request」，實際上它代表的是「請求將某個分支的變更合併（merge）到另一個分支」。

Pull Request 的主要功能與用途

功能 說明
✅ 讓他人審查程式碼（Code Review） 其他開發者可以查看、留言、建議或要求修改程式碼。
🧪 執行自動測試 / CI 可以觸發自動化流程，如單元測試、自動部署等。
🧾 顯示差異（diff） 可明確看到這次 PR 修改了哪些檔案、哪些程式碼行。
🔒 保護主要分支 通常會設定禁止直接推送到主分支，僅允許透過 PR 合併。
📜 追蹤歷史紀錄 PR 會保留完整的討論過程與變更歷史，讓開發流程透明且可追溯。

合併與推送方式比較

本地合併再推送

# 操作流程：
git checkout main
git merge feature/login
git push origin main
項目 說明
🔄 合併地點 在本機執行合併
📤 推送方式 使用 git push 將結果推送至遠端
✅ 效率 快速，無需審查即可合併
🔒 安全性 較低，容易不小心將 bug 推上主分支
📜 紀錄 僅有 Git log，無審查或討論紀錄

使用 GitHub Pull Request 進行合併

操作流程：

  1. 開發完功能；
  2. 將 feature/login 分支推送到 GitHub；
  3. 建立 PR：feature/login → main。
項目 說明
🔄 合併地點 在 GitHub 上操作
👀 支援審查 可讓其他人參與討論、給予意見與審核
✅ 可設定保護規則 例如：需兩人審核通過、CI 測試通過才能合併
📜 留下完整紀錄 包含討論、修正、審核與合併過程
🚫 降低失誤風險 可有效避免錯誤地推送到主分支

圖解比較

🧑‍💻 本地合併：

  [feature/login]     →     git merge     →     [main]
                         (在本機進行合併)
                                ↓
                          git push origin main


🌐 Pull Request 合併：

  [feature/login]  → push →  GitHub 上建立 PR
                                     ↓
                        → 審查、測試、按下合併按鈕 → [main]

哪種情境該選用哪種方式？

情境 建議方式
個人專案、小型測試 ✅ 本地合併即可
團隊合作、正式專案 ✅ 建議使用 Pull Request
需要保留討論紀錄 ✅ 使用 Pull Request
你是唯一負責人，無需他人審查 ✅ 本地合併即可