從0開始學習 GitHub 系列之「06.團隊合做利器 Branch」

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 分支，這個流程沒啥大問題。

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

4. Git Flow

準確的說 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 兩個分支。

想必你們已經瞭解了這個工具的具體做用，具體安裝與用法我就很少提了，感興趣的能夠看我下我以前寫過的一篇博客：

http://stormzhang.com/git/2014/01/29/git-flow/

5. 總結

以上就是我分享給大家的關於分支的全部知識，一我的你也許感覺不到什麼，可是實際工做中大都以團隊協做爲主，而分支是團隊協做必備技能，而 Git Flow 是我推薦給大家的一個很流行的分支管理流程，也是咱們薄荷團隊內部一直在實踐的一套流程，但願對大家有借鑑意義。

轉載地址： http://blog.csdn.NET/googdev/article/details/52787586