獨到見解

Git工作流程(阮一峰完整總結版本，各流程變化，且有獨到

見解)

Git作為一個源碼管理系統，不可避免涉及到多人協作。

協作必須有一個規范的工作流程，讓大家有效地合作，使得

項目井井有條地發展下去。"工作流程"在英語里，叫做

"workflow"或者"flow"，原意是水流，比喻項目像水流那樣，

順暢、自然地向前流動，不會發生沖擊、對撞、甚至漩渦。

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

Gitflow

Githubflow

Gitlabflow

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

《Git使用規范流程》

《常用Git命令清單》

《Git遠程操作詳解》

一、功能驅動

本文的三種工作流程，有一個共同點：都采用"功能驅動式開

發"（Feature-drivendevelopment，簡稱FDD）。

它指的是，需求是開發的起點，先有需求再有功能分支

（featurebranch）或者補丁分支（hotfixbranch）。完成開

發后，該分支就合并到主分支，然后被刪除。

二、Gitflow

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

2.1特點

它最主要的特點有兩個。

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

主分支master

開發分支develop

前者用于存放對外發布的版本，任何時候在這個分支拿到的，

都是穩定的分布版；后者用于日常開發，存放最新的開發版。

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

功能分支（featurebranch）

補丁分支（hotfixbranch）

預發分支（releabranch）

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

被刪除。

Gitflow的詳細介紹，請閱讀我翻譯的中文版《Git分支管

理策略》。

2.2評價

Gitflow的優點是清晰可控，缺點是相對復雜，需要同時維

護兩個長期分支。大多數工具都將master當作默認分支，

可是開發是在develop分支進行的，這導致經常要切換分支，

非常煩人。

更大問題在于，這個模式是基于"版本發布"的，目標是一段

時間以后產出一個新版本。但是，很多網站項目是"持續發布

"，代碼一有變動，就部署一次。這時，master分支和develop

分支的差別不大，沒必要維護兩個長期分支。

三、Githubflow

Githubflow是Gitflow的簡化版，專門配合"持續發布"。它

是使用的工作流程。

3.1流程

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

官方推薦的流程如下。

第一步：根據需求，從master拉出新分支，不區分功能分

支或補丁分支。

第二步：新分支開發完成后，或者需要討論的時候，就向

master發起一個pullrequest（簡稱PR）。

第三步：PullRequest既是一個通知，讓別人注意到你的請

求，又是一種對話機制，大家一起評審和討論你的代碼。對

話過程中，你還可以不斷提交代碼。

第四步：你的PullRequest被接受，合并進master，重新

部署后，原來你拉出來的那個分支就被刪除。（先部署再合

并也可。）

3.2評價

Githubflow的最大優點就是簡單，對于"持續發布"的產品，

可以說是最合適的流程。

問題在于它的假設：master分支的更新與產品的發布是一致

的。也就是說，master分支的最新代碼，默認就是當前的線

上代碼。

可是，有些時候并非如此，代碼合并進入master分支，并

不代表它就能立刻發布。比如，蘋果商店的APP提交審核

以后，等一段時間才能上架。這時，如果還有新的代碼提交，

master分支就會與剛發布的版本不一致。另一個例子是，有

些公司有發布窗口，只有指定時間才能發布，這也會導致線

上版本落后于master分支。

上面這種情況，只有master一個主分支就不夠用了。通常，

你不得不在master分支以外，另外新建一個production分

支跟蹤線上版本。

四、Gitlabflow

Gitlabflow是Gitflow與Githubflow的綜合。它吸取了

兩者的優點，既有適應不同開發環境的彈性，又有單一主分

支的簡單和便利。它是推薦的做法。

4.1上游優先

Gitlabflow的最大原則叫做"上游優先"（upsteamfirst），即

只存在一個主分支master，它是所有其他分支的"上游"。只

有上游分支采納的代碼變化，才能應用到其他分支。

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

為：

LinusTorvalds的分支

子系統（比如netdev）的分支

設備廠商（比如三星）的分支

4.2持續發布

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

對于"持續發布"的項目，它建議在master分支以外，再建立

不同的環境分支。比如，"開發環境"的分支是master，"預發

環境"的分支是pre-production，"生產環境"的分支是

production。

開發分支是預發分支的"上游"，預發分支又是生產分支的"上

游"。代碼的變化，必須由"上游"向"下游"發展。比如，生產

環境出現了bug，這時就要新建一個功能分支，先把它合并

到master，確認沒有問題，再cherry-pick到pre-production，

這一步也沒有問題，才進入production。

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

4.3版本發布

對于"版本發布"的項目，建議的做法是每一個穩定版本，都

要從master分支拉出一個分支，比如2-3-stable、2-4-stable

等等。

以后，只有修補bug，才允許將代碼合并到這些分支，并且

此時要更新小版本號。

五、一些小技巧

5.1PullRequest

功能分支合并進master分支，必須通過PullRequest（Gitlab

里面叫做MergeRequest）。

前面說過，PullRequest本質是一種對話機制，你可以在提

交的時候，@相關人員或團隊，引起他們的注意。

5.2Protectedbranch

master分支應該受到保護，不是每個人都可以修改這個分支，

以及擁有審批PullRequest的權力。

Github和Gitlab都提供"保護分支"（Protectedbranch）這

個功能。

5.3Issue

Issue用于Bug追蹤和需求管理。建議先新建Issue，再新

建對應的功能分支。功能分支總是為了解決一個或多個

Issue。

功能分支的名稱，可以與issue的名字保持一致，并且以

issue的編號起首，比如

"15-require-a-password-to-change-it"。

開發完成后，在提交說明里面，可以寫上"fixes#14"或者

"clos#67"。Github規定，只要commitmessage里面有

下面這些動詞+編號，就會關閉對應的issue。

clo

clos

clod

fix

fixes

fixed

resolve

resolves

resolved

這種方式還可以一次關閉多個issue，或者關閉其他代碼庫

的issue，格式是urname/repository#issue_number。

PullRequest被接受以后，issue關閉，原始分支就應該刪

除。如果以后該issue重新打開，新分支可以復用原來的名

字。

5.4Merge節點

Git有兩種合并：一種是"直進式合并"（fastforward），不生

成單獨的合并節點；另一種是"非直進式合并"（none

fast-forword），會生成單獨節點。

前者不利于保持commit信息的清晰，也不利于以后的回滾，

建議總是采用后者（即使用--no-ff參數）。只要發生合并，就

要有一個單獨的合并節點。

5.5Squash多個commit

為了便于他人閱讀你的提交，也便于cherry-pick或撤銷代碼

變化，在發起PullRequest之前，應該把多個commit合并

成一個。（前提是，該分支只有你一個人開發，且沒有跟

master合并過。）

這可以采用reba命令附帶的squash操作，具體方法請參

考我寫的《Git使用規范流程》。

（完）