在團隊使用 GIT 作為專案版本控制工具的過程中，除了團隊成員對於 GIT 需要有一定的掌握度，內部使用流程的挑選及制訂也是很重要的一環。除此之外還有一些非流程，也非 GIT 使用技能的原則，也很需要團隊成員都了解，在這篇我會先引用 GitLab 提出的 11 條規則，針對部分加上一些個人見解，跟大家做分享。

11 rules for the GitLab Workflow

1. Use feature branches, no direct commits on master.
2. Test all commits, not only ones on master.
3. Run all the tests on all commits (if your tests run longer than 5 minutes have them run in parallel).
4. Perform code reviews before merges into master, not afterwards.
5. Deployments are automatic, based on branches or tags.
6. Tags are set by the user, not by CI.
7. Releases are based on tags.
8. Pushed commits are never rebased.
9. Everyone starts from master, and targets master.
10. Fix bugs in master first and release branches second.
11. Commit messages reflect intent.

1. Use feature branches, no direct commits on master.

使用 feature 分支新增 commits 而不是直接在主分支上 Commit。

在流程中，凡事透過建立 feature 分支，在分支上驗證及實作，而不直接在主分支上作修訂。這項原則的好處是開發者可以透過 feature 分支，放手的嘗試及驗證，不用害怕修改錯誤而造成主要分支上無法回復的災難。另，就算再有自信，也不要直接跳過 MR 流程，直接在主分支上修改，很多災難，常常發生在很細微的地方，透過 MR 流程，讓團隊成員協助一起破除盲點，如此才能真正趨吉避凶。

實際上，建立分支的成本是很便宜的，如 Day 08 提到的，他只是一個可以移動的標籤貼紙，學理上只佔了 40字元，因此不用怕因為建立分支而浪費儲存庫的空間。

2. Test all commits, not only ones on master.

所有的 commits 都執行測試，而不是只在主分支上測試。

所有建立的分支都需要執行測試，而不是等到合併到主分支上才進行測試，這規則可以幫助團隊及早發現問題，早點發現問題的所花費的修復成本，往往比晚點發現來的便宜。

3. Run all the tests on all commits (if your tests run longer than 5 minutes have them run in parallel).

在所有的 commits 上執行所有的測試。如果測試需要執行超過五分鐘，那麼可以試著平行化執行

有些時候，可能會覺得執行所有測試會浪費資源又費時，但其實如同上一個原則，越早發現問題，越省成本，因此如果發現執行測試太耗資源或費時，可能就需要去評估測試資源的貧頸點在哪裡，試著去改善它。

4. Perform code reviews before merges into master, not afterwards.

在合併到主分支前作 code review，而不是在合併之後。

同樣的，這條原則也是基於早期發現問題解決問題，成本是比較小的。可以早點做團隊 code review 使團隊成員建立團隊共識及早針對問題作修改，所帶來的效益，會是比較好的。

如果原始碼合併回主要分支，才開始進行 Code Review 往往會變成形式，容易忽略一些細節，進而造成一些細小的問題擴大。

5. Deployments are automatic, based on branches or tags.

基於分支或標籤 (tag) 做部署(Deploy)，並且讓部署工作自動化。

透過自動化部屬，除了可以省去人力成本外，也可以降低人員部署所衍伸的操作錯誤議題。

6. Tags are set by the user, not by CI.

由使用者建立 tag，而不是讓 CI 工具建立 tag。

建立一個 tag 可以視為一個新版本的建立，由團隊成員決定是否要正式發佈版本，而不是讓 CI 工具主動的建立 tag，釋出版本。

7. Releases are based on tags.

使用 tag 作為版本發佈的依據。

8. Pushed commits are never rebased.

已經提交到共用分支的 commit，不要再進行 rebase。

相關的議題，在 Day 20 的討論中有提到，在已經提交到共用分支的 commit 上再次的進行 rebase，通常必須經過 git push 加上 -f 參數來進行，這動作不是不能做，而是要在確認團隊成員們都可以承受的狀況下執行。如果是個人的 feature 分支，只會影響到自己，那麼 rebase 再次更新到儲存庫上，其實並不會造成什麼影響。

9. Everyone starts from master, and targets master.

所有人都由主要分支 master 作為開始，且每次都以主要分支為基礎。

在 GitLab 定義的這 11 條規則，可以發現，很明確的不斷的在提醒，Day 29 所提到的 GitLab 是一個「upstream first」的流程，一切以主分支 master 為基礎，而向外延伸。

10. Fix bugs in master first and release branches second.

先在主要分支進行 bug 的修正，之後才發佈到分支

基於「upstream first」原則，就算在釋出版本中發現問題，也先在主要分支上建立 bug 修正的分支，而後一樣走 MR 流程，合併回主要分支之後，再透過主要分支發佈到需要修正的分支。

這段其實解決掉了兩個問題，一是，因為所有的流程都是由 master 開始，因此在釋出的版本中可以看到的問題，在 master 主分支上一定也會有，自然在主分支上解決了，同樣的解決方案在其他的分支也通常都能適用，但如果是相反過來，先在發現問題的分支作處理，而後才合併回主要分支，則可能無法套用。二是，因為一切由 master 開始，自然做什麼事情流程都是一致的，不會有 GitFlow 的流程複雜難懂的問題。

11. Commit messages reflect intent.

在 Commit message 中充分的表達修改的目的及意圖

在 Day 05 中有提到各種 commit message 撰寫的原則及方法，好的 commit message 不只是說明做了什麼，也應該說明為什麼這樣做，甚至可以解釋，為什麼不選擇其他方案。如此的累積，有時候幫助到的是後期再次來維護原始碼的自己。

除此之外

除了 GitLab 提到的這十一條規則，通常我個人還會在意：

1. 不要讓 feature 分支在自己手上太久
   通常不要讓一個工作太大，大到超過一天才能做完，但如果真的遇到無法合併回主分支的分支時，也要記得定期的讓這個分支對主分支作 rebase，避免該分支無法在較新版本的環境上使用。(有些做客製化的公司很容易遇到這樣的情境，當客制版本與公版永遠不合併時)
2. 在正式 push 到公用儲存區前，至少再次的透過 fetch 檢查共用分支上是否有新的變更。

總結：

除了這些原則外，GitLab 還有提到關於 Code Review 的參考標準，也有助於團隊內部在進行 Code Review 時的原則參考。

這是 用樂高玩轉 GIT 版本控制系列 的第三十篇，在一開始的前二十多篇，希望可以透過實物化來模擬 GIT 底層的原理，讓可以看到這系列的邦友們，真的可以因此讓 GIT 的基礎概念更加穩固，進而能才開始能衍伸基礎到實際運用上，而不害怕 GIT 的操作。

而後面近十篇的安排，則是基於基礎來延伸，狀況題是希望更活用基礎概念，而團隊協作流程的介紹，則是希望團隊在使用 GIT 時，有更多可以參考的流程優缺點來調整團隊內部流程。

最後，這系列的三十篇，真心希望可以幫助到一些對於 GIT 有點熟悉，但又不是太熟悉，在一些狀況下，總還會遇到難題的朋友。

當然如果還有其他的問題，也都還可以透過留言一起討論。

參考資料

• The 11 Rules of GitLab Flow
• Code Review Guidelines