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

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

通常當(dāng)我們?cè)谶M(jìn)行一個(gè)正式項(xiàng)目的時(shí)候，一定的分支管理是必要，這里推薦大家閱讀兩篇文章，我自己也是從這兩篇文章中受益匪淺。

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

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

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

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

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

一種是主要分支

一種是臨時(shí)分支

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

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

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

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

//在develop分支下運(yùn)行下面命令
git push origin develop 

將本地develop分支推送至遠(yuǎn)端倉(cāng)庫(kù)，如果遠(yuǎn)端沒(méi)有develop會(huì)自動(dòng)創(chuàng)建！

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

feature（功能分支）

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

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

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

介紹一下在這個(gè)過(guò)程中可能會(huì)用的git指令。

在開(kāi)發(fā)過(guò)程中會(huì)用到的：

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

//檢查項(xiàng)目中是否有未進(jìn)行版本控制和已修改的文件
git status 

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

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

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

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

//切換回develop分支
git checkout develop

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

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

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

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

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

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


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

//確認(rèn)release-1.0.0的分支沒(méi)有問(wèn)題了，我們就將分支合并到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:后面跟的是標(biāo)簽名；
# -m:后面跟的是改標(biāo)簽的說(shuō)明(一般可以不用加-m)

//推送master分支和tag到遠(yuǎn)程
git pull origin master
git push origin master
git push --tags

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

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

最后我們來(lái)了解一下bug修復(fù)分支，這個(gè)翻譯過(guò)來(lái)就是熱修復(fù)分支。估計(jì)是想強(qiáng)調(diào)線上bug修復(fù)，我們需要開(kāi)分支來(lái)進(jìn)行修復(fù)線上bug的。其實(shí)bug修復(fù)分支和上面講到的預(yù)發(fā)布分支幾乎是一個(gè)類(lèi)型的。不同的地方無(wú)非是，bug修復(fù)分支是在發(fā)布后修復(fù)線上bug，所以要從已經(jīng)發(fā)布的master分支上牽出hotfix分支。而release分支是在發(fā)布之前來(lái)進(jìn)行bug修復(fù)，所以從develop分支錢(qián)出來(lái)。但他們最終合并的時(shí)候都是要合并到master再合并到develop分支的。而最后，他們?cè)谕瓿闪烁髯缘氖姑螅际强梢詣h除的臨時(shí)分支！

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

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

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

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

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

//確認(rèn)hotfix-1.0.1的分支測(cè)試通過(guò)，我們就將分支合并到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:后面跟的是標(biāo)簽名；
# -m:后面跟的是改標(biāo)簽的說(shuō)明(一般可以不用加-m）

//推送master分支和tag到遠(yuǎn)程
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到遠(yuǎn)程了。
git branch -d hotfix-1.0.1
git pull origin develop 
git push origin develop   

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

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

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

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

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

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

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

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