在工作場合實施Git的時候，有很多種工作流程可供選擇，此時反而會讓你手足無措。本文羅列了企業團隊最常用的一些Git工作流程，包括Centralized Workflow、Feature Branch Workflow、Gitflow Workflow、Forking Workflow。願以此文拋磚引玉。

在你開始閱讀之前，請記住：這些流程應被視作為指導方針，而非“鐵律”。我們只是想告訴你可能的做法。因此，如果有必要的話，你可以組合使用不同的流程。

（本文主要介紹Gitflow Workflow……）

Vincent Driessen曾經寫過一篇博文，題為“A successful Git branching model

Gitflow工作流程圍繞專案釋出定義了嚴格的分支模型。儘管它比Feature Branch Workflow更復雜一些，但它也為管理更大規模的專案提供了堅實的框架。

與Feature Branch Workflow比起來，Gitflow流程並沒有增加任何新的概念或命令。其特色在於，它為不同的分支分配了非常明確的角色，並且定義了使用場景和用法。除了用於功能開發的分支，它還使用獨立的分支進行釋出前的準備、記錄以及後期維護。當然，你還是能充分利用Feature Branch Workflow的好處：拉拽請求（Pull Request）、隔離的試驗以及更高效率的合作。

它是怎麼工作的？

Gitflow流程仍然使用一箇中央程式碼倉庫，它是所有開發者的資訊交流中心。跟其他的工作流程一樣，開發者在本地完成開發，然後再將分支程式碼推送到中央倉庫。唯一不同的是專案中分支的結構。

用於記錄歷史的分支

Gitflow使用兩個分支來記錄專案開發的歷史，而不是使用單一的master分支。在Gitflow流程中，master只是用於儲存官方的釋出歷史，而develop分支才是用於整合各種功能開發的分支。使用版本號為master上的所有提交打標籤（tag）也很方便。

事實上，Gitflow流程就是圍繞這兩個特點鮮明的分支展開的。

用於功能開發的分支

每一個新功能的開發都應該各自使用獨立的分支。為了備份或便於團隊之間的合作，這種分支也可以被推送到中央倉庫。但是，在建立新的功能開發分支時，父分支應該選擇develop（而不是master）。當功能開發完成時，改動的程式碼應該被合併（merge）到develop分支。功能開發永遠不應該直接牽扯到

注意：組合使用功能開發分支和develop分支的這種設計，其實完全就是Feature Branch Workflow的理念。然而，Gitflow流程並不止於此。且看下文分解。

用於釋出的分支

一旦develop分支積聚了足夠多的新功能（或者預定的釋出日期臨近了），你可以基於develop分支建立一個用於產品釋出的分支。這個分支的建立意味著一個釋出週期的開始，也意味著本次釋出不會再增加新的功能——在這個分支上只能修復bug，做一些文件工作或者跟釋出相關的任務。在一切準備就緒的時候，這個分支會被合併入master，並且用版本號打上標籤。另外，釋出分支上的改動還應該合併入develop分支——在釋出週期內，develop分支仍然在被使用（一些開發者會把其他功能整合到develop分支）。

使用專門的一個分支來為釋出做準備的好處是，在一個團隊忙於當前的釋出的同時，另一個團隊可以繼續為接下來的一次釋出開發新功能。這也有助於清晰表明開發的狀態，比如說，團隊在彙報狀態時可以輕鬆使用這樣的措辭，“這星期我們要為釋出4.0版本做準備。”從程式碼倉庫的結構上也能直接反映出來。常用的一些措辭還有：基於develop新建分支，合併入master；命名規則為：release-*或release/*

用於維護的分支

釋出後的維護工作或者緊急問題的快速修復也需要使用一個獨立的分支。這是唯一一種可以直接基於master建立的分支。一旦問題被修復了，所做的改動應該被合併入master和develop分支（或者用於當前釋出的分支）。在這之後，master上還要使用更新的版本號打好標籤。

這種為解決緊急問題專設的綠色通道，讓團隊不必打亂當前的工作流程，也不必等待下一次的產品釋出週期。你可以把用於維護的分支看成是依附於master的一種特別的釋出分支。

* 舉例說明 *

下面的例子將演示Gitflow流程如何被用來管理一次產品釋出。假設你已經建立好了一箇中央倉庫。

1.     建立develop分支

第一步是給預設的master配備一個develop分支。一種簡單的做法是：讓一個開發者在本地建立一個空的develop分支，然後把它推送到伺服器。

git branch develop
git push -u origin develop

develop分支將包含專案的所有歷史，而master會是一個縮減版本。現在，其他開發者應該克隆（clone）中央倉庫，並且為develop建立一個追蹤分支。

git clone ssh://[email protected]/path/to/repo.git
git checkout -b develop origin/develop

到現在，所有人都把包含有完整歷史的分支（develop）在本地配置好了。

2.     小馬和小明開始開發新功能

我們的故事從小馬和小明要分別開發新功能開始。他們倆各自建立了自己的分支。注意，他們在建立分支時，父分支不能選擇master，而要選擇develop。

git checkout -b some-feature develop

他們倆都在自己的功能開發分支上開展工作。通常就是這種Git三部曲：edit，stage，commit：

git status
git add <some-file>
git commit

3.     小馬把她的功能開發好了

在提交過幾次程式碼之後，小馬覺得她的功能做完了。如果她所在的團隊使用“拉拽請求”，此刻便是一個合適的時機——她可以提出一個將她所完成的功能合併入develop分支的請求。要不然，她可以自行將她的程式碼合併入本地的develop分支，然後再推送到中央倉庫，像這樣：

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

第一條命令確保了本地的develop分支擁有最新的程式碼——這一步必須在將功能程式碼合併之前做！注意，新開發的功能程式碼永遠不能直接合併入master。必要時，還需要解決在程式碼合併過程中的衝突。

4.     小馬開始準備一次釋出

儘管小明還在忙著開發他的功能，小馬卻可以開始準備這個專案的第一次正式釋出了。類似於功能開發，她使用了一個新的分支來做產品釋出的準備工作。在這一步，釋出的版本號也最初確定下來。

git checkout -b release-0.1 develop

這個分支專門用於釋出前的準備，包括一些清理工作、全面的測試、文件的更新以及任何其他的準備工作。它與用於功能開發的分支相似，不同之處在於它是專為產品釋出服務的。

一旦小馬建立了這個分支並把它推向中央倉庫，這次產品釋出包含的功能也就固定下來了。任何還處於開發狀態的功能只能等待下一個釋出週期。

5.     小馬完成了釋出

一切準備就緒之後，小馬就要把釋出分支合併入master和develop分支，然後再將釋出分支刪除。注意，往develop分支的合併是很重要的，因為開發人員可能在釋出分支上修復了一些關鍵的問題，而這些修復對於正在開發中的新功能是有益的。再次提醒一下，如果小馬所在的團隊強調程式碼評審（Code Review），此時非常適合提出這樣的請求。

git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1

釋出分支扮演的角色是功能開發（develop）與官方釋出（master）之間的一個緩衝。無論什麼時候你把一些東西合併入master，你都應該隨即打上合適的標籤。

git tag -a 0.1 -m"Initial public release" master
git push --tags

Git支援鉤子（hook）的功能，也就是說，在程式碼倉庫裡某些特定的事件發生的時候，可以執行一些預定義的指令碼。因此，一種可行的做法是：在伺服器端配置一個鉤子，當你把master推送到中央倉庫或者推送標籤時，Git伺服器能為產品釋出進行一次自動的構建。

6.     使用者發現了一個bug

當一次釋出完成之後，小馬便回去與小明一起開發其他功能了。突然，某個使用者提出抱怨說當前釋出的產品裡有一個bug。為了解決這個問題，小馬（或者小明）基於master建立了一個用於維護的分支。她在這個分支上修復了那個bug，然後把改動的程式碼直接合併入master。

git checkout -b issue-#001 master
# Fix the bug
git checkout master
git merge issue-#001
git push

跟用於釋出的分支一樣，在維護分支上的改動也需要合併入develop分支，這一點是很重要的！因此，小馬務必不能忘了這一步。隨後，她就可以將維護分支刪除。

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001