Q:用fork再合併 跟用branch再合併的差異是什麼?

A:最大的差別是 發出 merge requset 的使用者對要合併入的分支"有沒有寫入權限"

Branch 再合併（在同一個 repository）

• 在同一個專案內建立分支
• 適合有寫入權限的團隊成員使用
• 工作流程：
  1. git checkout -b feature-branch
  2. 開發並 commit
  3. push 到同一個 repo：git push origin feature-branch
  4. 發 Pull Request 合併回主分支

Fork 再合併（跨 repository）

• 複製整個 repository 到你的帳號下
• 適合沒有寫入權限的外部貢獻者
• 工作流程：
  1. 在 GitHub 上 Fork 專案
  2. Clone 你 fork 的版本
  3. 建立分支並開發
  4. Push 到你自己的 fork
  5. 發 Pull Request 從你的 fork 合併到原始 repo

主要差異

特性	Branch	Fork
權限需求	需要寫入權限	不需要原始 repo 的權限
Repository	同一個	兩個獨立的 repo
使用場景	內部團隊協作	開源專案貢獻
管理複雜度	較簡單	需要同步 upstream

在公司內部的專案，通常用 branch 就夠了。但如果是要貢獻開源的 library，就需要先 fork。

Q:為什麼叫 Pull Request

A:這個名稱其實蠻有趣的，從接收方的角度來命名

為什麼叫 “Pull” Request？

當你完成開發後，你是在請求專案維護者把你的改動 pull（拉取）進來。

換個角度想：

• 你的視角：我想把程式碼「推」給你
• 維護者的視角：有人請求我「拉取」他的改動

所以叫 Pull Request = 「請求你拉取我的改動」

實際流程

你的分支/Fork → (發 PR) → 請求合併 → 維護者 pull 你的改動

GitLab 的命名

有趣的是，GitLab 把同樣的功能叫做 Merge Request (MR)，從結果來命名——「請求合併」，這樣其實更直觀一些。

歷史原因

Pull Request 這個詞來自 GitHub，當時的設計理念是：

• 貢獻者：git push 到自己的 fork
• 維護者：git pull 貢獻者的改動

所以用 “Pull Request” 這個名稱，強調的是維護者需要執行的動作。

簡單說，Pull Request = 我做好了，請你拉取我的程式碼來審查和合併！