一、前言

git 最強大的就是其分支功能，但是如何分支才能更有效的提高開發效率，減少因為程式碼合併帶來的問題，需要一個分支模型來規範，其實在 git flow 出現之前，已經有分支模型理論流程，當時是根據此理論，手動的按照規範操作分支，git flow 出現之後，將一部分操作流程簡化為命令，並沒有增加新的功能，只是簡化了操作。

二、git-flow 簡介

安裝git-flow後，你將會擁有一些擴充套件命令。這些命令會在一個預定義的順序下自動執行多個操作。 git-flow 並不是要替代 Git，它僅僅是非常聰明有效地把標準的 Git 命令用指令碼組合了起來。 嚴格來講，你並不需要安裝什麼特別的東西就可以使用 git-flow

三、安裝

目前流行的是 avh 版本的 git-flow

# 穩定版
brew install git-flow-avh
# 開發板
brew install git-flow-avh --HEAD

四、初始化專案

# cd /pass/to/your/project
# 執行下面的命令，不需要執行 git init
git flow init

五、分支模型

用 git flow 初始化工程目錄完成後，只能看到兩個分支：

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

master 分支

用於上線的分支，保護性分支，只包含經過測試的穩定程式碼，開發人員不能直接工作在此分支上，也不能直接提交改動到 master 分支上。

develop分支

是開發人員進行任何新的開發的基礎分支，當開始一個新的feature 分支的時候，要從 develop 分出去；另外此分支也彙集所有的已完成的功能，等待合併到 master 分支上線。

上面兩個分支被稱為長期分支 ，存在於專案的整個生命週期中，其他分支，是臨時性的，根據需要來建立，當完成了自己的任務後，就會被刪掉。

feature 分支

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

1. 開始一個feature分支

如下命令會建立一個名為”feature/” 的功能分支，該分支預設從 develop檢出，在做功能性開發的時候，檢出一個獨立的分支，是版本控制中一個重要 的原則。

# git-flow 建立 feature 分支
$ git flow feature start <branch-name>

2. 完成一個feature分支

# git-flow 完成一個 feature 分支 
$ git flow feature finish <branch-name>

該命令會把我們在當前分支的程式碼整合到‘develop’分支中去，之後，git-flow 會進行清理操作，刪除當下完成的功能分支，將分支切換到‘develop’。

release 分支

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

1.建立一個release分支

當你認為現在在 “develop” 分支的程式碼已經是一個成熟的 release 版本時，這意味著：第一，它包括所有新的功能和必要的修復；第二，它已經被徹底的測試過了。如果上述兩點都滿足，那就是時候開始生成一個新的 release 了：

$ git flow release start 1.1.5
Switched to a new branch 'release/1.1.5'

請注意，release 分支是使用版本號命名的。這是一個明智的選擇，這個命名方案還有一個很好的附帶功能，那就是當我們完成了release 後，git-flow 會適當地_自動_去標記那些 release 提交。

有了一個 release 分支，再完成針對 release 版本號的最後準備工作（如果專案裡的某些檔案需要記錄版本號），並且進行最後的編輯。

2. 完成一個release分支

$ git flow release finish 1.1.5

這個命令會完成如下一系列的操作：

1. 首先，git-flow 會拉取遠端倉庫，以確保目前是最新的版本。
2. 然後，release 的內容會被合併到 “master” 和 “develop” 兩個分支中去，這樣不僅產品程式碼為最新的版本，而且新的功能分支也將基於最新程式碼。
3. 為便於識別和做歷史參考，release 提交會被標記上這個 release 的名字（在我們的例子裡是 “1.1.5”）。
4. 清理操作，版本分支會被刪除，並且回到 “develop”。

從 Git 的角度來看，release 版本現在已經完成。依據你的設定，對 “master” 的提交可能已經觸發了你所定義的部署流程，或者你可以通過手動部署，來讓你的軟體產品進入你的使用者手中。

hotfix分支

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

1. 建立一個hotfix分支

$ git flow hotfix start missing-link

這個命令會建立一個名為“hotfix/missing-link” 的分支。因為這是對產品程式碼進行修復，所以這個hotfix分支是基於“master”分支。

這也是和 release 分支最明顯的區別，release 分支都是基於 “develop” 分支的。因為你不應該在一個還不完全穩定的開發分支上對產品程式碼進行地修復。

就像 release 一樣，修復這個錯誤當然也會直接影響到專案的版本號！

2.完成一個hotfix分支

在把我們的修復提交到hotfix分支之後，就該去完成它了：

$ git flow hotfix finish missing-link

這個過程非常類似於釋出一個 release 版本：

• 完成的改動會被合併到 “master” 中，同樣也會合併到 “develop” 分支中，這樣就可以確保這個錯誤不會再次出現在下一個 release 中。
• 這個 hotfix 會被標記起來以便於參考。
• 這個 hotfix 分支將被刪除，然後切換到 “develop” 分支上去。

還是和產生 release 的流程一樣，現在需要編譯和部署你的產品（如果這些操作不是自動被觸發的話）。

六、總結

主要分支

master: 專案的主要分支，對外的第一門面。所有人瀏覽專案，使用專案，第一時間看到的是master。永遠處在即將釋出(production-ready)狀態。

develop: 處於功能開發的最前線的版本，檢視develop分支就能知道下一個釋出版本有哪些功能了。develop一開始是從master裡分出來的，並且定期會合併到master裡，每一次合併到master，表示我們完成了一個階段的開發，產生一個穩定版。同樣的，develop下也不建議直接開發程式碼，develop代表的是已經開發好的功能的迴歸版本。最後，在適當的時候，由合適的人，合併到master，作為下一個穩定版本。

feature的作用是為每一個新功能從develop裡創建出來的一個分支。例如小明和小白分別做兩個不相干的功能，就應該分別建立兩個分支，各自開發完以後，先後合併到develop裡，這就叫做迴歸。

輔助分支

feature: 開發新功能的分支, 基於 develop, 完成後 merge 回 develop

release: 準備要釋出版本的分支, 也基於 develop, 完成後 merge 回 develop 和 master

hotfix: 修復 master 上的問題, 等不及 release 版本就必須馬上上線. 基於 master, 完成後 merge回 master 和 develop