在上一篇中，提到了 GitFlow，這個流程，對於各種狀態需要開不一樣性質的分支，且有時候只需要合併到一個分支，特殊情境，如 release、hotfix 又需要合併到兩個分支，這大大的考驗了團隊成員使用 GIT 的能力。而今天要介紹的的 GitHub Flow 則是另外一個面向的流程，官方標榜著他是 lightweight, branch-based workflow。
如上圖 GitHub 可以說只有五個階段分別是：
建立一個分支。GitHub Flow 的流程中，只會有一個隨時都存在的分支，也就是 master，因此所有的分支都由 master 開立，建立分支之後，開發者可以任意的做自己想做的驗證測試，而不會影響到 master 分支上的原始碼。建立分支的這個階段，對於儲存庫寫入權限的開發者，則是使用 fork 的機制到自己有權限的儲存庫上做原始碼修改，而後的流程則完全一致。(什麼是 fork 可以參考 Day 23)
在開分支的時候，分支的命名是重要的 GitHub 官方的手冊上建議，建立的分支名稱，應該要是有意義的，官方舉例如：refactor-authentication、user-content-cache-key、make-retina-avatars，從分支的名稱上，共同開發者們就可以知道這個分支建立的目的是什麼，一般實務上，命名甚至會加上 Issue 追蹤系統的 Issue Number，讓開發者們從分支名稱就可以知道對應的 Issue 為何。
在 GitHub 的流程中，所有的變更發布等，都是透過分支來完成，因此主分支 master 上的每個 commit 點，都是可以部署的版本。
在建立分支之後，就可以開幹了開始進行原始碼的編修了，且無論是否已經完成此次建立分支所要完成的事務，都可以 push 到共同分支上，透過 Commit message，讓團隊成員都可以知道目前該分支對應的工作之工作進度。也建議，不要讓一個 commit 做太多事情，盡可能就只完成該工作的一小件事情，讓每件小事情不要有太多的耦合，使真的發生錯誤時，好修改，甚至是直接可進行 revert；至於怎麼讓 Commit message 好讀，可以參考 Day 04、Day 05 的內容。
有時候，並不一定是完成一件事情之後才開始建立 PR，如果有任何需要與團隊成員討論時，也可以透過 PR 的機制，與成員討論，在 GitHub 的 PR 討論介面中，使用者甚至可以透過介面分享截圖，也可以透過 GitHub 的 @mention 功能，請求特定人員來進行查看與協助。怎麼建立 Pull Request 的方法，可以參考 Day 23 的內容。
建立 PR 之後，團隊的成員及主要的 Code Review 者，就可以透過這個 PR 所建立的討論區，開始進行討論，期間可以針對 Code Style、內部 Guideline等討論及修改，在這個位置，如內部有搭配的持續整合(Continuous Integration, CI)系統，通常也會在這時間點進行。
在討論的過程中，如果有任何需要再針對原始碼修改的內容，建立 PR 的原作者也可以再次重新 push 該分支，不用再重建 PR。
正式合併到到 Mater 分支之前，在這個階段可以先部署到測試環境，以進行合併前的最終測試。如果測試沒有通過或產生任何可以討論的議題，則可以取消合併，在正式通過後才正式發佈到正式環境上。
在經過前述的步驟一切都通過後，則正式合併到 master 主要分支中，合併之後，相關的修改記錄還是可以透過 commit 及對應的 commit message 查詢到，也可以透過因為 PR 所建立的討論區，找到討論紀錄。
在這時間點，基本已經完成所有的 GitHub 流程。
GitHub 相對於上一篇的 GitFlow 單純許多，總結就兩件事情：GitHub 主要分支就只有 master，而任何變更都是透過建立一個新分支來修改，而後透過 PR 的機制進行討論，當確認該修改可行之後，審查者只需要點選同意，系統會自動合併到主分支，相對容易懂。
在下一篇，將會介紹 GitLab Flow，對我來說，他是一個介於 GitHub Flow 以及 GitFlow 中間的的流程，它沒有 GitFlow 那麼複雜，又滿足一些 GitHub Flow 無法滿足的需求。
iThome鐵人賽
看影片追技術