Git 協作流程

協作必須有一個規范的流程，讓大家有效地合作，使得項目井井有條地發展下去。"協作流程"在英語里，叫做"workflow"或者"flow"，原意是水流，比喻項目像水流那樣，順暢、自然地向前流動，不會發生沖擊、對撞、甚至漩渦。

本文介紹三種廣泛使用的協作流程：

如果你對Git還不是很熟悉，可以先閱讀下面的文章。

一、功能驅動

本文的三種協作流程，有一個共同點：都采用 "功能驅動式開發" （Feature-driven development，簡稱FDD）。

它指的是，需求是開發的起點，先有需求再有功能分支（feature branch）或者補丁分支（hotfix branch）。完成開發后，該分支就合并到主分支，然后被刪除。

二、Git flow

最早誕生、并得到廣泛采用的一種協作流程，就是 Git flow 。

2.1 特點

它最主要的特點有兩個。

首先，項目存在兩個長期分支。

前者用于存放對外發布的版本，任何時候在這個分支拿到的，都是穩定的分布版；后者用于日常開發，存放最新的開發版。

其次，項目存在三種短期分支。

一旦完成開發，它們就會被合并進 develop 或 master ，然后被刪除。

Git flow 的詳細介紹，請閱讀我翻譯的中文版《Git 分支管理策略》。

2.2 評價

Git flow的優點是清晰可控，缺點是相對復雜，需要同時維護兩個長期分支。大多數工具都將 master 當作默認分支，可是開發是在 develop 分支進行的，這導致經常要切換分支，非常煩人。

更大問題在于，這個模式是基于"版本發布"的，目標是一段時間以后產出一個新版本。但是，很多網站項目是"持續發布"，代碼一有變動，就部署一次。這時， master分支和 develop 分支的差別不大，沒必要維護兩個長期分支。

三、Github flow

Github flow 是Git flow的簡化版，專門配合"持續發布"。它是 Github.com 使用的協作流程。

3.1 流程

它只有一個長期分支，就是 master ，因此用起來非常簡單。

官方推薦的 流程 如下。

3.2 評價

Github flow 的最大優點就是簡單，對于"持續發布"的產品，可以說是最合適的流程。

問題在于它的假設： master 分支的更新與產品的發布是一致的。也就是說，master 分支的最新代碼，默認就是當前的線上代碼。

可是，有些時候并非如此，代碼合并進入 master 分支，并不代表它就能立刻發布。比如，蘋果商店的APP提交審核以后，等一段時間才能上架。這時，如果還有新的代碼提交， master 分支就會與剛發布的版本不一致。另一個例子是，有些公司有發布窗口，只有指定時間才能發布，這也會導致線上版本落后于 master 分支。

上面這種情況，只有 master 一個主分支就不夠用了。通常，你不得不在 master分支以外，另外新建一個 production 分支跟蹤線上版本。

四、Gitlab flow

Gitlab flow 是 Git flow 與 Github flow 的綜合。它吸取了兩者的優點，既有適應不同開發環境的彈性，又有單一主分支的簡單和便利。它是 Gitlab.com 推薦的做法。

4.1 上游優先

Gitlab flow 的最大原則叫做"上游優先"（upsteam first），即只存在一個主分支master ，它是所有其他分支的"上游"。只有上游分支采納的代碼變化，才能應用到其他分支。

Chromium項目 就是一個例子，它明確規定，上游分支依次為：

4.2 持續發布

Gitlab flow 分成兩種情況，適應不同的開發流程。

對于"持續發布"的項目，它建議在 master 分支以外，再建立不同的環境分支。比如，"開發環境"的分支是 master ，"預發環境"的分支是 pre-production ，"生產環境"的分支是 production 。

開發分支是預發分支的"上游"，預發分支又是生產分支的"上游"。代碼的變化，必須由"上游"向"下游"發展。比如，生產環境出現了bug，這時就要新建一個功能分支，先把它合并到 master ，確認沒有問題，再 cherry-pick 到 pre-production ，這一步也沒有問題，才進入 production 。

只有緊急情況，才允許跳過上游，直接合并到下游分支。

4.3 版本發布

對于"版本發布"的項目，建議的做法是每一個穩定版本，都要從 master 分支拉出一個分支，比如 2-3-stable 、 2-4-stable 等等。

以后，只有修補bug，才允許將代碼合并到這些分支，并且此時要更新小版本號。

五、一些小技巧

5.1 Pull Request

功能分支合并進 master 分支，必須通過Pull Request（Gitlab里面叫做 Merge Request）。

前面說過，Pull Request本質是一種對話機制，你可以在提交的時候， @ 相關 人員或 團隊 ，引起他們的注意。

5.2 Protected branch

master 分支應該受到保護，不是每個人都可以修改這個分支，以及擁有審批 Pull Request 的權力。

Github 和 Gitlab 都提供"保護分支"（Protected branch）這個功能。

5.3 Issue

Issue 用于 Bug追蹤和需求管理。建議先新建 Issue，再新建對應的功能分支。功能分支總是為了解決一個或多個 Issue。

功能分支的名稱，可以與issue的名字保持一致，并且以issue的編號起首，比如"15-require-a-password-to-change-it"。

開發完成后，在提交說明里面，可以寫上"fixes #14"或者"closes #67"。Github規定，只要commit message里面有下面這些 動詞 + 編號，就會關閉對應的issue。

這種方式還可以一次關閉多個issue，或者關閉其他代碼庫的issue，格式是username/repository#issue_number 。

Pull Request被接受以后，issue關閉，原始分支就應該刪除。如果以后該issue重新打開，新分支可以復用原來的名字。

5.4 Merge節點

Git有兩種合并：一種是"直進式合并"（fast forward），不生成單獨的合并節點；另一種是"非直進式合并"（none fast-forword），會生成單獨節點。

前者不利于保持commit信息的清晰，也不利于以后的回滾，建議總是采用后者（即使用 --no-ff 參數）。只要發生合并，就要有一個單獨的合并節點。

5.5 Squash 多個commit

為了便于他人閱讀你的提交，也便于 cherry-pick 或撤銷代碼變化，在發起Pull Request之前，應該把多個commit合并成一個。（前提是，該分支只有你一個人開發，且沒有跟 master 合并過。）

這可以采用 rebase 命令附帶的 squash 操作，具體方法請參考我寫的《Git 使用規范流程》。