摘要：如上圖，該圖沒有現(xiàn)成的，所以是在大師原有的上修改出來的我們在開發(fā)過程中，通常以當(dāng)天下午下班前十分鐘為節(jié)點，合并當(dāng)日修復(fù)的代碼到分支另外要說的就是分支的命名了，通常我們已即將發(fā)布的版本號為后綴添加到后面，例如等等。

首發(fā)公眾號：Android程序員日記
作者：賢榆的榆
如果你覺得有幫助歡迎關(guān)注、贊賞、轉(zhuǎn)發(fā)
閱讀時間：5622字 15分鐘

通常當(dāng)我們在進行一個正式項目的時候，一定的分支管理是必要，這里推薦大家閱讀兩篇文章，我自己也是從這兩篇文章中受益匪淺。

第一篇是國外行家Vincent Driessen 的《A successful Git branching model》
地址：https://nvie.com/posts/a-succ...
第二篇阮一峰老師的《Git分支管理策略》
地址：http://www.ruanyifeng.com/blo...

其實阮一峰老師寫了關(guān)于git的一個系列文章。如果對git還不太熟悉的，非常推薦閱讀，圖文并茂，淺顯易懂！

好了，那么接下來，我就站在前人的肩膀上結(jié)合這自己的實踐，來簡單介紹一下上面兩篇文章中提到的分支管理策略吧。我們先來看一張圖哪位外國哥們的圖。

小聲聲明：這部分幾乎所有的圖片都引用自《A successful Git branching model》這篇博客。

看圖的最上面，出現(xiàn)了feture branches、develop、release branches、hotfixes、master。看似總共五種分支，但其實這其中歸納一下只有兩種：

一種是主要分支

一種是臨時分支

那么我們先來說一下主要分支。從上面的圖里，其實我們也不難看出來，develop和master 是兩個主干分支。與臨時分支的唯一區(qū)別時，他們包含了所以其他臨時分支的提交。

在主要分支中，master是在我們運行g(shù)it init 之后就會默認生成的分支，所以我們的其他所以分支的起點應(yīng)該都是從master分支check出去的。另外我們通常也正是用這個master分支也用來記錄我們的每一個生產(chǎn)版本，所以每一次合并其他分支到mater分支時，都應(yīng)該非常的謹慎。

在主要分支中，develop是我們的開發(fā)分支，是從master 切出來的。而最終當(dāng)我們開發(fā)完成之后，我們都一定會將其合并回master，然后打出一個生產(chǎn)包，在用tag標記一個版本的發(fā)行。master與develop分支的關(guān)系圖如下：

又一個git 命令可以學(xué)一下

//在develop分支下運行下面命令
git push origin develop 

將本地develop分支推送至遠端倉庫，如果遠端沒有develop會自動創(chuàng)建！

主要分支說完了，那我們聊一聊臨時分支吧。在Vincent Driessen的那篇文章中，稱之為Supporting branches（支持分支）。其實都是一樣的了，他按照分支的作用來歸類命名。我是根據(jù)分支的生命周期的角度給了此命名。通過對這組分支的命名大家應(yīng)該都已經(jīng)了解到了。臨時分具有一定的實效行，它往往承載的是一段時間里的一件獨立的事。所以這里我們通常分出了三種：

feature（功能分支）

hotfix（bug修復(fù)分支）

release-（發(fā)布版分支）

先說說功能分支吧。通常我們從develop分支上切出一個新的分支來開發(fā)一個新的功能，并且我們通常以該功能命名。比如在我最近的一個項目中做了一個消息通知的功能，于是我切了一個新的分支叫inform。最后當(dāng)我們將該功能開發(fā)完之后仍會將其合并到devleop分支。當(dāng)然如果只有一個人那似乎用不用功能分支都不重要。所以分支管理最重要的是進行更好的團隊協(xié)作，達到到敏捷迭代，高效開發(fā)，在技術(shù)層面快速占領(lǐng)市場。下面是feature與devleop的關(guān)系圖，注意這里的branches是復(fù)數(shù)，哈哈，細節(jié)很重要：

介紹一下在這個過程中可能會用的git指令。

在開發(fā)過程中會用到的：

//從devleop切出一個新的分支命名為
//feature_name(這個名字你可以自定義)
git checkout -b feature_name develop

//檢查項目中是否有未進行版本控制和已修改的文件
git status 

//將項目當(dāng)前目錄下所有文件到暫存區(qū)
git add .

//提交暫存取里的代碼到本地庫
git commit -m"提交log"

//當(dāng)然你也可能會用到上面講到過的一個命令
//這個只取決于你是否想將這個臨時分支，推送到遠程服務(wù)器進行管理
git push origin feature_name 

在功能分支開發(fā)完成之后會用到的：

//切換回develop分支
git checkout develop

//將feature_name分支合并到develop
git merge --no-ff feature_name
    
// 刪除本地的feature_name 分支
git branch -d feature_name
    
//將develop分支推送到遠端服務(wù)器,一定要先pull再push
git pull origin develop 
git push origin develop     

這里merge 后面跟了--no-ff ，加不加它有什么區(qū)別呢，我們現(xiàn)在這里賣個關(guān)子，在文章最后，會進行補充說明。

release是一個預(yù)發(fā)布分支。在一個迭代中，當(dāng)我們完成了一個或者幾個小功能之后，我們會把feature 分支們都合并到develop分支上，這時develop分支其實就可以作為一個預(yù)發(fā)布分支了。但是如果還有其他小伙伴正在開發(fā)下一個迭代發(fā)布的功能。那么極有可能出現(xiàn)一種情況，就是他在功能分支上面開發(fā)完成了，卻無法合并到develop分支上，因為此時的develop分支已經(jīng)同時承載了預(yù)發(fā)布階段的性能優(yōu)化、bug修復(fù)并等代發(fā)布上線等任務(wù)，是不能夠合并其他分支的代碼的。所以這個時候我們就非常需要從develop分支牽出一個新的分支來作為完成我們預(yù)發(fā)布階段的相關(guān)功能。而這就是我們的release分支了。所以release分支也會在這期間將修復(fù)后的代碼頻繁的合并到develop分支上。（如上圖，該圖沒有現(xiàn)成的，所以是在大師原有的keynote上修改出來的）我們在開發(fā)過程中，通常以當(dāng)天下午下班前十分鐘為節(jié)點，合并當(dāng)日修復(fù)的代碼到develop分支！

另外要說的就是release分支的命名了，通常我們已即將發(fā)布的版本號為后綴添加到release-后面，例如：release-2.0.0、release-2.2.2等等。

介紹一下release分支生命周期中可能會用的git指令流程。

//首先從develop分支牽出release-1.0.0分支
git checkout -b release-1.0.0


//接著我們會檢查、添加到緩存區(qū)、提交到本地
git status
git add .
git commit -m"修復(fù)bug2018"

//確認release-1.0.0的分支沒有問題了，我們就將分支合并到master分支
git checkout  master
git merge --no-ff release-1.0.0

//在master分支上打上tag
git tag -a v1.0.0 -m"release v1.0.0"
# -a:后面跟的是標簽名；
# -m:后面跟的是改標簽的說明(一般可以不用加-m)

//推送master分支和tag到遠程
git pull origin master
git push origin master
git push --tags

//合并分支到develop
git checkout develop
git merge --no-ff release-1.0.0

//最后可以刪除分支然后推送develop到遠程了。
git branch -d release-1.0.0
git pull origin develop 
git push origin develop   

最后我們來了解一下bug修復(fù)分支，這個翻譯過來就是熱修復(fù)分支。估計是想強調(diào)線上bug修復(fù)，我們需要開分支來進行修復(fù)線上bug的。其實bug修復(fù)分支和上面講到的預(yù)發(fā)布分支幾乎是一個類型的。不同的地方無非是，bug修復(fù)分支是在發(fā)布后修復(fù)線上bug，所以要從已經(jīng)發(fā)布的master分支上牽出hotfix分支。而release分支是在發(fā)布之前來進行bug修復(fù)，所以從develop分支錢出來。但他們最終合并的時候都是要合并到master再合并到develop分支的。而最后，他們在完成了各自的使命之后，都是可以刪除的臨時分支！

關(guān)于hotfix 的命名，大家也可以參考這release分支的命名來！如果我們是修復(fù)1.0.0 的線上版本，那么修復(fù)之后的版本號應(yīng)該是是1.0.1，那么我們就可以給這個hotfix 分支取名為hotfix-1.0.1

即：hotfix-   +  即將發(fā)布的版本號
這個也是僅供參考，如果你有更好的方案，也歡迎在公眾號后臺留言給我！

在bug 修復(fù)分支的生命周期里，我們會用的git操作其實和release分支大致是一樣的，不過這里也還是在羅列一下，也是大家可以看著git的變化，把握它們的邏輯！

//首先從develop分支牽出release-1.0.0分支
git checkout -b hotfix-1.0.1

//修復(fù)完成后去檢查、添加到緩存區(qū)、提交到本地
git status
git add .
git commit -m"修復(fù)線上bug"

//確認hotfix-1.0.1的分支測試通過，我們就將分支合并到master分支
git checkout  master
git merge --no-ff hotfix-1.0.1

//在master分支上打上tag
git tag -a v1.0.1 -m"hotfix-v1.0.1"  
# -a:后面跟的是標簽名；
# -m:后面跟的是改標簽的說明(一般可以不用加-m）

//推送master分支和tag到遠程
git pull origin master
git push origin master
git push --tags

//合并分支到develop
git checkout develop
git merge --no-ff hotfix-1.0.1

//最后可以刪除hotfix-1.0.1分支然后推送develop到遠程了。
git branch -d hotfix-1.0.1
git pull origin develop 
git push origin develop   

看到這里，關(guān)于git 分支的管理模型就已經(jīng)了解的差不多了額，接下來也該填一下前面挖下的坑了。相信早就有同學(xué)疑問，為什么我們的merge 使用的是git merge --no-ff 而不是直接用git merge 。其實除了這兩種我們還有一種git merge —squash。這里我們就來區(qū)分一下吧！
先看圖（改圖最左邊的圖由我本人補充）

1、git merge feature
默認fast-forward 模式，如上圖最右邊的分支合并，不是沒有合并，develop分支的HEAD 直接指給了feature分支的HEAD 然后就呈現(xiàn)了這樣的狀態(tài)，但這種合并是有條件的——當(dāng)我們從develop分支切出feature分支開始，到feature分支開發(fā)完合并到develop分支之前，develop分支都不能有新的提交，才會使用fast-forward模式進行合并。否則即使你用這個命令也會讓你以第二種模式合并。

2、git merge --no-ff feature
--no-ff ，看著命令再結(jié)合前面提到的默認模式?；疽呀?jīng)猜出其意思了，就是強行關(guān)閉fast-forward。如上圖中中間的哪一組分支合并圖。當(dāng)我們使用這種模式進行合并的時候，它就會創(chuàng)建出一個新的合并分支節(jié)點作為當(dāng)前分支的HEAD。用這種方式，我們能夠更清晰看到分支完成的內(nèi)容和分支的起止時間。所以更多的時候我們是推薦使用這種合并方式的。

注：當(dāng)我們在命令行里執(zhí)行了上面的合并命令后，會彈出上圖所示內(nèi)容。這是通過Vim去修改本次提交的備注。它默認給的是Merge branch "feature" into develop 一般我都用默認，不修改，直接輸入：wq然后回車就保存退出了

3、git merge --squash feature
這個模式是將feature分支上的左右的改動提交都合成一個點作為develop的一次commit。通常我們使用的場景是如果我們切出一個分支來修復(fù)bug 然后出現(xiàn)了很多的補充提交和小改動的提交，看起來這些都很冗余沒有必要，那么我們就可以用這種模式。該模式提交完了的最終形態(tài)有點像fast-forward模式。并且它不同于上面兩種模式的一點是，你執(zhí)行了這個命令之后，只是把 feature分支上的所有改動都移植到了develop分支上的相應(yīng)文件上。接下來我們還需要自己再手動 add . --> commit 一次?？梢耘浜戏种Ш喜D的最左邊的示意圖理解一下！

好了總算把Git分支管理模型這塊說完了。在前面兩篇分享中，有小伙伴說要跟著這個一起擼。這確實是個不錯的主義，只是這次的內(nèi)容沒有太多讓大家擼的。但是在這里還是強烈建議大家新建一個GitDemo項目好好理解一下這樣的一個git 分支管理模型。雖然在后面的文章中我也會用這套模型來進行g(shù)it 分支管理，但是畢竟我是一個人在寫，所以并不能很好的模擬多人開發(fā)的分支管理，所以理解這個模型，大家還是需要親力親為的！

這篇文章就到這里吧，另外啰嗦兩句，這個系列的文章基本會涉及到我們開發(fā)到上線整個流程的內(nèi)容，所以有的時候像這篇文章一樣，寫一些需要我們在開發(fā)過程中應(yīng)該有一定認知的東西，而不僅僅停留在一些代碼上。

好了，下一篇應(yīng)該會寫一些開發(fā)過程中能夠提高我們工作效率的一些插件。你可以在我的公眾號下面回復(fù)「Settings」，提前拿到我的Android Studio的配置導(dǎo)入到自己的Android Studio里了解一下！