Git 作為一個源碼管理系統，不可避免涉及到多人協作。
協作必須有一個規范的工作流程，讓大家有效地合作，使得項目井井有條地發展下去。"工作流程"在英語里，叫做"workflow"或者"flow"，原意是水流，比喻項目像水流那樣，順暢、自然地向前流動，不會發生沖擊、對撞、甚至漩渦。
本文介紹三種廣泛使用的工作流程：
Git flow
Github flow
Gitlab flow
如果你對Git還不是很熟悉，可以先閱讀下面的文章。
一、功能驅動
本文的三種工作流程，有一個共同點：都采用"功能驅動式開發"（Feature-driven development，簡稱FDD）。
它指的是，需求是開發的起點，先有需求再有功能分支（feature branch）或者補丁分支（hotfix branch）。完成開發后，該分支就合并到主分支，然后被刪除。
二、Git flow
最早誕生、并得到廣泛采用的一種工作流程，就是Git flow。
2.1 特點
它最主要的特點有兩個。
首先，項目存在兩個長期分支。
主分支master
開發分支develop
前者用于存放對外發布的版本，任何時候在這個分支拿到的，都是穩定的分布版；后者用于日常開發，存放最新的開發版。
其次，項目存在三種短期分支。
功能分支（feature branch）
補丁分支（hotfix branch）
預發分支（release branch）
一旦完成開發，它們就會被合并進develop或master，然后被刪除。
Git flow 的詳細介紹，請閱讀我翻譯的中文版《Git 分支管理策略》。
2.2 評價
Git flow的優點是清晰可控，缺點是相對復雜，需要同時維護兩個長期分支。大多數工具都將master當作默認分支，可是開發是在develop分支進行的，這導致經常要切換分支，非常煩人。
更大問題在于，這個模式是基于"版本發布"的，目標是一段時間以后產出一個新版本。但是，很多網站項目是"持續發布"，代碼一有變動，就部署一次。這時，master分支和develop分支的差別不大，沒必要維護兩個長期分支。
三、Github flow
Github flow是Git flow的簡化版，專門配合"持續發布"。它是 Github.com 使用的工作流程。
3.1 流程
它只有一個長期分支，就是master，因此用起來非常簡單。
官方推薦的流程如下。
第一步：根據需求，從master拉出新分支，不區分功能分支或補丁分支。
第二步：新分支開發完成后，或者需要討論的時候，就向master發起一個pull request（簡稱PR）。
第三步：Pull Request既是一個通知，讓別人注意到你的請求，又是一種對話機制，大家一起評審和討論你的代碼。對話過程中，你還可以不斷提交代碼。
第四步：你的Pull Request被接受，合并進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項目就是一個例子，它明確規定，上游分支依次為：
Linus Torvalds的分支
子系統（比如netdev）的分支
設備廠商（比如三星）的分支
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。
close
closes
closed
fix
fixes
fixed
resolve
resolves
resolved
這種方式還可以一次關閉多個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操作
