貢獻在 GitHub 上的專案

這篇文章是用來記錄我從零開始學習 git，為了能夠貢獻一點程式到 gitHub 上。希望這篇記錄不單能作為學習的記錄，也能夠幫助到其它也想幫忙 gitHub 上專案，但是不知道如何下手的人。

先備知識

首先要先談談 git 的特性，和其它老牌的版本管理不同，早期在建立本地「沙箱(sendbox)」的時候採用 checkout 來得到某個特定版本資料，而 git 則採用 clone 的方式，將版本庫整個複製回本機上，因此除了要和遠端的版本庫同步的工作外，都可以在沒有網路的本機端完成所有操作。

要注意的是，本地和遠端的版本庫實際上是獨立的個體，依需求可以隨意連結或斷開關連。因此一個本地版本庫同時對兩個以上遠端保持關連是可行的。在推送(push)新版本的時候，只需要告訴 git 遠端主機是哪一個就好了。許多的 git 特性，都是由這個特性延申而來。

情境說明

先說說我的情形⋯

• 在網路看到想要加入的專案，開放讓人貢獻程式碼
• 但自己並沒有寫入這個專案的權限，既使有權限，也不知道應該如何作修改
• 聽聞程式碼送交後，會有人進行審核，但找不到送審的地方，也不知道審核者在哪裡
• 在討論區裡知道了有 fork 這東東，但版本庫 fork 回來，接著就不知道要作什麼了

關於我學習中間撞牆的詳細過程，不是這篇文章的細節。也許哪天有空再寫篇雜記吧！

我歸結出的操作流程

大體上貢獻的流程如下所列，其中前兩項的順序可以反過來。

1. fork 想貢獻的版本庫
2. 取得版本庫資料
3. 建立和 fork 版本庫的關連
4. 建立分支並作內容的修改或相關編輯，送交到分支中
5. 建立 Pull Ruquest，請求審核加入
6. 最後，和審核者討論修改的內容，等得審核者合併回原始的版本庫

底下就簡單說說各階段作的事情⋯

fork 想貢獻的版本庫

在專案首頁中，應該可以在右上角的地方找到「 Fork 」的按鈕，按下去就行了。當然，你得先有一個 gitHub 帳號，登入後才完成這個動作。

fork 動作和 clone 類似，將別的地方的版本庫複雜一份回自己的空間，因為在自己的空間，所以當然就有對這個複製出的版本庫有完整的存取權。不過這並不表示你也有對於原版本庫的寫入權限，原本的和剛 fork 出來的版本庫兩者之間獨立的，不會具有連動或是什麼交互影響的地方。要一直到後面提到的 Pull Request 才會有一些關連。

取得版本庫的資料

利用指令或是使用一些 UI 工具抓回要貢獻的版本庫的資料，這裡指的不是剛剛 fork 回來的那個版本庫，而是被 fork 的那個。這種作法，git 會自動把 origin 的標籤交給被 fork 的那個版本庫。在 git 上遠端標籤只是一個代號，因此這算是個人偏好，讓自己比較不會搞錯原始位置和自己 fork 的版本庫代號。

git clone [版本庫的網址]

建立和 fork 版本庫的關連

現在要建立和 fork 版本庫的關連，使用 UI 工具或是下面的指令建立和 fork 資料庫連結。指令中的「myfork」也是由網路資料上學來的，用來方便辨認出是 fork 回來的。

git remote add myfork [fork 的版本庫網址]

在這裡補充說明一下，雖然遠端版本連結建立的順序沒有差異，但是我希望預設(不指定名字時候)的遠端是原始版本庫，這樣每一次使用 fetch 或 pull指令更新本地時，就能很容易取得原始位置上最新的資料。而不是指到 fork 回來的版本庫，當然不會有任何新資料(因為它只會由自己 push 上去)。因此這樣子的順序安排，有助之後進行其它的貢獻。

建立分支並作內容的修改或相關編輯，送交到分支中

git 的建議，修改多在分支上進行。所以就取個容易理解的名字，進行對應的修改。然後再把這個分支內容，推送到自己 fork 回來的版本庫中。

建立 Pull Ruquest，請求審核加入

當完成分支內容的送交後，就可以回到 gitHub 網站上，選擇、進入剛剛送交的分支。在畫面最右邊，有垂直一排的選單，其中第二個就叫作 pull request，點選後依照畫面的操作，就可以發出 pull request，告訴原始版本庫的管理者，我這裡的這個分支中，有修正用的資料，要不要抓回去看看？

最後，和審核者討論修改的內容，等得審核者合併回原始的版本庫

發出 Pull Request 後，在原始版本庫的介面中也能夠看得到。審核者可能會對於得到的分支給予意見，中間可能需要重新送交修正版本到分支裡，這個時候不需要重新發出 pull request，審核者會知道。

等到都沒有問題了，會由有權限的人將你的程式回併到原始版本庫中，這個時候，為了修正這個錯誤的分支，因為已經被併入其它分支（或主幹），所以已經可以被刪掉了。

如果還有其它要修改的，回到分支的步驟再來過

git 的思想之一，就是一個 bug 在一個分支中解決。除了因為 git 在建立分支所耗費的資源很低之外，也為了讓每個 bug （或新功能）都能有最大的選擇併入主幹的彈性，不會因為卡在某個不能上線的功能，導致整包東西都上不了線。因此，如果有其它的修改想法，就再多開個新的分支吧！

要注意的是，一個公開多人貢獻的專案，可能在問題修改完成前，就有好幾個新版本被上傳，所以要記得常常更新自己本地端的資料，利用 rebase 的方式，讓自己的修改總是由最新的主幹版本出發。避免 pull request 發出，審核者無法驗證而退貨狀況發生。

結語

老實說，自己也才好不容易完成一次 gitHub 的程式碼貢獻，後來就因為好幾個公私事占用了不少時間，沒有再提交其它程式。因此這一系列的作法，裡頭可能會有一些小錯誤，不過對於一個完全不了解 fork 概念的人來說，應該多少能提供一些思考的方向。