Git 相比於 SVN 最強大的一個地方就在於「分支」，Git 的分支操作簡直不要太方便，而實際項目開發中團隊合作最依賴的莫過於分支了，關於分支前面的系列也提到過，但是本篇會詳細講述什麽是分支、分支的具體操作以及實際項目開發中到底是怎麽依賴分支來進行團隊合作的。

1.什麽是分支？

我知道讀者中肯定有些人對分支這個概念比較模糊，其實你們可以這麽理解，你們幾個人一起去旅行，中間走到一個三岔口，每條路可能有不同的風景，你們約定 3 天之後在某地匯聚，然後各自出發了。而這三條分叉路就可以理解成你們各自的分支，而等你們匯聚的時候相當於把你們的分支進行了合並。

2.分支的常用操作

通常我們默認都會有一個主分支叫 master ，下面我們先來看下關於分支的一些基本操作：

新建一個叫 develop 的分支

git branch develop  

這裏稍微提醒下大家，新建分支的命令是基於當前所在分支的基礎上進行的，即以上是基於 mater 分支新建了一個叫做 develop 的分支，此時 develop 分支跟 master 分支的內容完全一樣。如果你有 A、B、C三個分支，三個分支是三位同學的，各分支內容不一樣，如果你當前是在 B 分支，如果執行新建分支命令，則新建的分支內容跟 B 分支是一樣的，同理如果當前所在是 C 分支，那就是基於 C 分支基礎上新建的分支。

切換到 develop 分支

git checkout develop 

如果把以上兩步合並，即新建並且自動切換到 develop 分支：

git checkout -b develop  

把 develop 分支推送到遠程倉庫

git push origin develop  

如果你遠程的分支想取名叫 develop2 ，那執行以下代碼：

git push origin develop:develop2  

但是強烈不建議這樣，這會導致很混亂，很難管理，所以建議本地分支跟遠程分支名要保持一致。

查看本地分支列表

git branch 

查看遠程分支列表

git branch -r  

刪除本地分支

git branch -d develop    

git branch -D develop (強制刪除)  

刪除遠程分支

git push origin :develop  

如果遠程分支有個 develop ，而本地沒有，你想把遠程的 develop 分支遷到本地：

git checkout develop origin/develop    

同樣的把遠程分支遷到本地順便切換到該分支：

git checkout -b develop origin/develop  

3.基本的團隊協作流程

一般來說，如果你是一個人開發，可能只需要 master、develop 兩個分支就 ok 了，平時開發在 develop 分支進行，開發完成之後，發布之前合並到 master 分支，這個流程沒啥大問題。

如果你是 3、5 個人，那就不一樣了，有人說也沒多大問題啊，直接可以新建 A、B、C 三個人的分支啊，每人各自開發各自的分支，然後開發完成之後再逐步合並到 master 分支。然而現實卻是，你正在某個分支開發某個功能呢，這時候突然發現線上有一個很嚴重的 bug ，不得不停下手頭的工作優先處理 bug ，而且很多時候多人協作下如果沒有一個規範，很容易產生問題，所以多人協作下的分支管理規範很重要，就跟代碼規範一樣重要，以下就跟大家推薦一種我們內部在使用的一種分支管理流程 Git Flow。

4.Git Flow

我們都知道, 在 git 的分支功能相對 svn 確實方便許多，而且也非常推薦使用分支來做開發. 我的做法是每個項目都有2個分支, master 和 develop. master 分支是主分支, 保證程序有一個 穩定版本, develop 則是開發用的分支, 幾乎所有的功能開發, bug 修復都在這個分支上, 完成後 再合並回 master.

但是情況並不是這麽簡單. 有時當我們正在開發一個功能, 但程序突然出現 bug 需要及時去修復的時候, 這時要切回 master 分支, 並基於它創建一個 hotfix 分支. 有時我們在開發一個功能時, 需要停下來去開發另一個功能. 而且所有這些問題都出現 的時候, 發布也會成為比較棘手問題.

也就是說, git branch 功能很強大，但是沒有一套模型告訴我們應該怎樣在開發的時候善用 這些分支。於是有人就整理出了一套比較好的方案 A successful Git branching model, 今天我們就一起來學習下這套方案.

準確的說 Git Flow 是一種比較成熟的分支管理流程，我們先看一張圖能清晰的描述他整個的工作流程：

第一次看上面那個圖是不是一臉懵逼？跟我當時一樣，不急，我來用簡單的話給你們解釋下。

一般開發來說，大部分情況下都會擁有兩個分支 master 和 develop，他們的職責分別是：

master：永遠處在即將發布(production-ready)狀態

develop：最新的開發狀態

確切的說 master、develop 分支大部分情況下都會保持一致，只有在上線前的測試階段 develop 比 master 的代碼要多，一旦測試沒問題，準備發布了，這時候會將 develop 合並到 master 上。

但是我們發布之後又會進行下一版本的功能開發，開發中間可能又會遇到需要緊急修復 bug ，一個功能開發完成之後突然需求變動了等情況，所以 Git Flow 除了以上 master 和 develop 兩個主要分支以外，還提出了以下三個輔助分支：

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

release: 準備要發布版本的分支, 用來修復 bug，基於 develop，完成後 merge 回 develop 和 master

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

什麽意思呢？

舉個例子，假設我們已經有 master 和 develop 兩個分支了，這個時候我們準備做一個功能 A，第一步我們要做的，就是基於 develop 分支新建個分支：

git branch feature/A   

看到了吧，其實就是一個規範，規定了所有開發的功能分支都以 feature 為前綴。

但是這個時候做著做著發現線上有一個緊急的 bug 需要修復，那趕緊停下手頭的工作，立刻切換到 master 分支，然後再此基礎上新建一個分支：

git branch hotfix/B  

代表新建了一個緊急修復分支，修復完成之後直接合並到 develop 和 master ，然後發布。

然後再切回我們的 feature/A 分支繼續著我們的開發，如果開發完了，那麽合並回 develop 分支，然後在 develop 分支屬於測試環境，跟後端對接並且測試的差不多了，感覺可以發布到正式環境了，這個時候再新建一個 release 分支：

git branch release/1.0  

這個時候所有的 api、數據等都是正式環境，然後在這個分支上進行最後的測試，發現 bug 直接進行修改，直到測試 ok 達到了發布的標準，最後把該分支合並到 develop 和 master 然後進行發布。

以上就是 Git Flow 的概念與大概流程，看起來很復雜，但是對於人數比較多的團隊協作現實開發中確實會遇到這麽復雜的情況，是目前很流行的一套分支管理流程，但是有人會問每次都要各種操作，合並來合並去，有點麻煩，哈哈，這點 Git Flow 早就想到了，為此還專門推出了一個 Git Flow 的工具，並且是開源的：

GitHub 開源地址：https://github.com/nvie/gitflow

簡單點來說，就是這個工具幫我們省下了很多步驟，比如我們當前處於 master 分支，如果想要開發一個新的功能，第一步切換到 develop 分支，第二步新建一個以 feature 開頭的分支名，有了 Git Flow 直接如下操作完成了：

git flow feature start A  

這個分支完成之後，需要合並到 develop 分支，然而直接進行如下操作就行：

git flow feature finish A  

如果是 hotfix 或者 release 分支甚至會自動幫你合並到 develop、master 兩個分支。

想必大家已經了解了這個工具的具體作用，具體安裝與用法如下：

A successful Git branching model

主要分支

• **master: **永遠處在即將發布(production-ready)狀態
• **develop: **最新的開發狀態

輔助分支

• feature: 開發新功能的分支, 基於 develop, 完成後 merge 回 develop
• release: 準備要發布版本的分支, 用來修復 bug. 基於 develop, 完成後 merge 回 develop 和 master
• hotfix:修復 master 上的問題, 等不及 release 版本就必須馬上上線. 基於 master, 完成後 merge 回 master 和 develop
  作者還提供了 git-flow 命令工具:

$ git flow init

接著它會問你一系列的問題，蛋定！盡量使用它的默認值就好了：

No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

完成後當前所在分支就變成 develop. 任何開發都必須從 develop 開始:

git flow feature start some_awesome_feature

完成功能開發之後:

git flow feature finish some_awesome_feature

該命令將會把feature/some_awesome_feature合並到develope分支，然後刪除功能(feature)分支。

將一個 feature 分支推到遠程服務器:

git flow feature publish some_awesome_feature
或者
git push origin feature/some_awesome_feature

當你的功能點都完成時（需要發布新版本了），就基於develop創建一個發布(release)分支，然後升級版本號並在最後發布日期前把Bug Fix掉吧：

$ git flow release start v0.1.0

當你在完成（finish)一個發布分支時，它會把你所作的修改合並到master分支，同時合並回develop分支，所以，你不需要擔心你的master分支比develop分支更加超前。

最後一件讓git-flow顯得威武的事情是它處理熱修復（即時的BugFix）的能力，你可以像其他分支一樣地創建和完成一個熱修復分支，區別是它基於master分支，因此你可以在產品出現問題時快速修復，然後通過”finish”命令把修改合並回master和develop分支。

GitHub 系列之「團隊合作利器 Branch」