現今許多 OpenSource 專案都會使用 GIT 作版本控制，也使用 GitHub、GitLab 等作為共用儲存庫，而通常這些專案，除了有主要的開發人員，也可以接受網友提供修改建議，甚至是直接提供修改後的原始碼供合併到專案中。

問題是，通常這些專案都會做權限控管，讓有權限的開發人員才能直接新增或合併 commit 到專案中，那麼沒有這些權限的使用者該怎麼樣有效的協助專案作原始碼的修正或改善呢？

一、複製 OpenSource 專案到自己的共用儲存庫 Fork

當看到一份 OpenSource 專案，自己有能力提供修正或改善，或在合理範圍內，想直接複製一份到自己的儲存庫的時候，就可以使用 Fork 的功能。值得一說，Fork 的功能，並不是 GIT 本身所提供的功能，但無論是 GitHub 或是 GitLab 都有提供。

所謂的 Fork 也就是把來源的共用儲存庫當下的儲存庫完整的複製一份到自己有權限控制的共用儲存庫，來源的共用儲存庫什麼 GIT 物件、分支等，在目標的共用儲存庫也都會有一份。

以 GitHub 為例：

在每個專案頁面上的右上角，都可以看到一個「Fork」的按鈕，當點選時，即可直接複製一份到自己帳號或組織的儲存庫中。

點選後，系統在一小段作業時間之後，即可在自己的專案中看到同樣的一個儲存庫。

如上圖，(這邊以兩個帳號 mouson及mousontw 為例，以 mousontw Fork mouson 的儲存庫)可以發現兩個儲存庫的 HASH Code 及 Commit 都是一樣的，且會在專案上顯示 Fork 的來源。

當 Fork 完畢之後，就可以針對想修改的內容進行原始碼的編輯及修正。

二、為專案提供修正或改善 PR (Pull Request) / MR (Merge Request)

當修正完畢之後，想要給來源專案提供新的原始碼，在 GitHub 上，這個動作稱為「Pull Request」簡稱「PR」或 GitLab 上，稱為「Merge Request」簡稱「MR」，這邊以 GitHub 的頁面為例：

在專案或專案上「Pull request」的頁面上，都可以看到「Compare & pull request」的按鈕。

點選後系統會根據原本這個專案 Fork 的來源做好基本的設定，但還是要注意 Open a pull request 的目標及分支名稱要選擇正確，base repository 為接受這次 PR 的對象，head repository 為自己的儲存庫，選擇正確後，可以在標題及內容中說明，這個 PR 的目的及原因。

標題及內容的撰寫，在某些專案上有定義樣板，內容就必須符合其原則，否則除可能會被退 PR，也會造成查看 PR 者的負擔。撰寫完畢之後點選「Create pull request」按鈕，完成 PR 發送。

按下「Create pull request」後，系統會有一段判斷程式碼是否造成衝突的過程，判斷完畢後會顯示「This branch has no conflicts with the base branch」

接著是「接收 PR 」端

在 GitHub 上，接收 PR 時，除了會收到電子郵件通知外。

也可以在 GitHub 網站的介面上看到通知，上面會顯示 PR 的來源及目標。

點選進入之後，可以看到以下的畫面，這邊分為三個框框分別是：01 紫色、02 橘色、03 紅色。

• 01 紫色：如果還有需要跟PR來源的作者討論時，可以在這邊與作者交流留言。
• 02 橘色：「Close pull request」如果這個 PR 判斷後不需要合併，則可以選擇此按鈕。
• 03 紅色：還記得 Day 21 及 Day 22 的各種合併方法嗎？在「Merge pull request」的這個按鈕下，都可以看到，這邊又依照自己專案的規範選擇合併的方法。在這時間點，除了可以保留來源作者提供的 commit message 外，也可以自己修改。

在正式點選接受 pull request 之前，可以依照專案的規範進行原始碼的「Code Review」、「測試」等流程。

總結：

Fork 及MR 與 PR 這部分的說明內容，原本並不在預計要說明的內容，但突然發現，之後說明 GIT 的流程時，如果沒有提到 Fork 及 PR 與 MR 可能會造成內容不夠連續，所以還是決定自己再說明一次。

今天的內容大部分以 GitHub 提供的畫面為主，如果有需要查看 GitLab 的畫面及流程內容，可以參考艦長正瑋今年的鐵人賽文章，關於 GitLab 流程的文章是這篇。