梁飛宇

一、前言

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

二、git-flow 簡介

安裝git-flow后，你將會擁有一些擴展命令。這些命令會在一個預定義的順序下自動執行多個操作。 git-flow 并不是要替代 Git，它僅僅是非常聰明有效地把標準的 Git 命令用腳本組合了起來。 嚴格來講，你并不需要安裝什么特別的東西就可以使用 git-flow 工作流程。你只需要了解，哪些工作流程是由哪些單獨的任務所組成的，并且附帶上正確的參數，以及在一個正確的順序下簡單執行那些對應的 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