「Do.008」Android 實戰項目（3）——Git 分支管理模型

首發公衆號： Android程序員日記
做者： 賢榆的榆
若是你以爲有幫助歡迎 關注、讚揚、轉發
閱讀時間：5622字 15分鐘

一般當咱們在進行一個正式項目的時候，必定的分支管理是必要，這裏推薦你們閱讀兩篇文章，我本身也是從這兩篇文章中受益不淺。

第一篇是國外行家Vincent Driessen 的《A successful Git branching model》
地址：https://nvie.com/posts/a-succ...

第二篇阮一峯老師的《Git分支管理策略》
地址：http://www.ruanyifeng.com/blo...

其實阮一峯老師寫了關於git的一個系列文章。若是對git還不太熟悉的，很是推薦閱讀，圖文並茂，淺顯易懂！

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

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

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

• 一種是主要分支
• 一種是臨時分支

主要分支

那麼咱們先來講一下主要分支。從上面的圖裏，其實咱們也不難看出來，develop和master 是兩個主幹分支。與臨時分支的惟一區別時，他們包含了因此其餘臨時分支的提交。

一、master分支

在主要分支中，master是在咱們運行git init 以後就會默認生成的分支，因此咱們的其餘因此分支的起點應該都是從master分支check出去的。另外咱們一般也正是用這個master分支也用來記錄咱們的每個生產版本，因此每一次合併其餘分支到mater分支時，都應該很是的謹慎。

二、devleop分支

在主要分支中，develop是咱們的開發分支，是從master 切出來的。而最終當咱們開發完成以後，咱們都必定會將其合併回master，而後打出一個生產包，在用tag標記一個版本的發行。master與develop分支的關係圖以下：

又一個git 命令能夠學一下

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

將本地develop分支推送至遠端倉庫，若是遠端沒有develop會自動建立！

臨時分支

主要分支說完了，那咱們聊一聊臨時分支吧。在Vincent Driessen的那篇文章中，稱之爲Supporting branches（支持分支）。其實都是同樣的了，他按照分支的做用來歸類命名。我是根據分支的生命週期的角度給了此命名。經過對這組分支的命名你們應該都已經瞭解到了。臨時分具備必定的實效行，它每每承載的是一段時間裏的一件獨立的事。因此這裏咱們一般分出了三種：

• feature（功能分支）
• hotfix（bug修復分支）
• release-（發佈版分支）

一、feature（功能分支）

先說說功能分支吧。一般咱們從develop分支上切出一個新的分支來開發一個新的功能，而且咱們一般以該功能命名。好比在我最近的一個項目中作了一個消息通知的功能，因而我切了一個新的分支叫inform。最後當咱們將該功能開發完以後仍會將其合併到devleop分支。固然若是隻有一我的那彷佛用不用功能分支都不重要。因此分支管理最重要的是進行更好的團隊協做，達到到敏捷迭代，高效開發，在技術層面快速佔領市場。下面是feature與devleop的關係圖，注意這裏的branches是複數，哈哈，細節很重要：

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

在開發過程當中會用到的：

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

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

//將項目當前目錄下全部文件到暫存區
git add .

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

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

在功能分支開發完成以後會用到的：

//切換回develop分支
git checkout develop

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

這裏merge 後面跟了--no-ff ，加不加它有什麼區別呢，咱們如今這裏賣個關子，在文章最後，會進行補充說明。

二、release（預發佈分支）

release是一個預發佈分支。在一個迭代中，當咱們完成了一個或者幾個小功能以後，咱們會把feature 分支們都合併到develop分支上，這時develop分支其實就能夠做爲一個預發佈分支了。可是若是還有其餘小夥伴正在開發下一個迭代發佈的功能。那麼極有可能出現一種狀況，就是他在功能分支上面開發完成了，卻沒法合併到develop分支上，由於此時的develop分支已經同時承載了預發佈階段的性能優化、bug修復並等代發佈上線等任務，是不可以合併其餘分支的代碼的。因此這個時候咱們就很是須要從develop分支牽出一個新的分支來做爲完成咱們預發佈階段的相關功能。而這就是咱們的release分支了。因此release分支也會在這期間將修復後的代碼頻繁的合併到develop分支上。（如上圖，該圖沒有現成的，因此是在大師原有的keynote上修改出來的）咱們在開發過程當中，一般以當天下午下班前十分鐘爲節點，合併當日修復的代碼到develop分支！

另外要說的就是release分支的命名了，一般咱們已即將發佈的版本號爲後綴添加到release-後面，例如：release-2.0.0、release-2.2.2等等。

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

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


//接着咱們會檢查、添加到緩存區、提交到本地
git status
git add .
git commit -m"修復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

三、hotfix（bug修復分支）

最後咱們來了解一下bug修復分支，這個翻譯過來就是熱修復分支。估計是想強調線上bug修復，咱們須要開分支來進行修復線上bug的。其實bug修復分支和上面講到的預發佈分支幾乎是一個類型的。不一樣的地方無非是，bug修復分支是在發佈後修復線上bug，因此要從已經發布的master分支上牽出hotfix分支。而release分支是在發佈以前來進行bug修復，因此從develop分支錢出來。但他們最終合併的時候都是要合併到master再合併到develop分支的。而最後，他們在完成了各自的使命以後，都是能夠刪除的臨時分支！

關於hotfix 的命名，你們也能夠參考這release分支的命名來！若是咱們是修復1.0.0 的線上版本，那麼修復以後的版本號應該是是1.0.1，那麼咱們就能夠給這個hotfix 分支取名爲hotfix-1.0.1

即：hotfix- + 即將發佈的版本號
這個也是僅供參考，若是你有更好的方案，也歡迎在公衆號後臺留言給我！

在bug 修復分支的生命週期裏，咱們會用的git操做其實和release分支大體是同樣的，不過這裏也仍是在羅列一下，也是你們能夠看着git的變化，把握它們的邏輯！

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

//修復完成後去檢查、添加到緩存區、提交到本地
git status
git add .
git commit -m"修復線上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

補充——merge的三種模式

看到這裏，關於git 分支的管理模型就已經瞭解的差很少了額，接下來也該填一下前面挖下的坑了。相信早就有同窗疑問，爲何咱們的merge 使用的是git merge --no-ff 而不是直接用git merge 。其實除了這兩種咱們還有一種git merge —squash。這裏咱們就來區分一下吧！
先看圖（改圖最左邊的圖由我本人補充）

一、git merge feature
默認fast-forward 模式，如上圖最右邊的分支合併，不是沒有合併，develop分支的HEAD 直接指給了feature分支的HEAD 而後就呈現了這樣的狀態，但這種合併是有條件的——當咱們從develop分支切出feature分支開始，到feature分支開發完合併到develop分支以前，develop分支都不能有新的提交，纔會使用fast-forward模式進行合併。不然即便你用這個命令也會讓你以第二種模式合併。

二、git merge --no-ff feature
--no-ff ，看着命令再結合前面提到的默認模式。基本已經猜出其意思了，就是強行關閉fast-forward。如上圖中中間的哪一組分支合併圖。當咱們使用這種模式進行合併的時候，它就會建立出一個新的合併分支節點做爲當前分支的HEAD。用這種方式，咱們可以更清晰看到分支完成的內容和分支的起止時間。因此更多的時候咱們是推薦使用這種合併方式的。

注：當咱們在命令行裏執行了上面的合併命令後，會彈出上圖所示內容。這是經過Vim去修改本次提交的備註。它默認給的是Merge branch 'feature' into develop 通常我都用默認，不修改，直接輸入：wq而後回車就保存退出了

三、git merge --squash feature
這個模式是將feature分支上的左右的改動提交都合成一個點做爲develop的一次commit。一般咱們使用的場景是若是咱們切出一個分支來修復bug 而後出現了不少的補充提交和小改動的提交，看起來這些都很冗餘沒有必要，那麼咱們就能夠用這種模式。該模式提交完了的最終形態有點像fast-forward模式。而且它不一樣於上面兩種模式的一點是，你執行了這個命令以後，只是把 feature分支上的全部改動都移植到了develop分支上的相應文件上。接下來咱們還須要本身再手動 add . --> commit 一次。能夠配合分支合併圖的最左邊的示意圖理解一下！

Git分支管理模型說完了

好了總算把Git分支管理模型這塊說完了。在前面兩篇分享中，有小夥伴說要跟着這個一塊兒擼。這確實是個不錯的主義，只是此次的內容沒有太多讓你們擼的。可是在這裏仍是強烈建議你們新建一個GitDemo項目好好理解一下這樣的一個git 分支管理模型。雖然在後面的文章中我也會用這套模型來進行git 分支管理，可是畢竟我是一我的在寫，因此並不能很好的模擬多人開發的分支管理，因此理解這個模型，你們仍是須要親力親爲的！

這篇文章就到這裏吧，另外囉嗦兩句，這個系列的文章基本會涉及到咱們開發到上線整個流程的內容，因此有的時候像這篇文章同樣，寫一些須要咱們在開發過程當中應該有必定認知的東西，而不只僅停留在一些代碼上。

好了，下一篇應該會寫一些開發過程當中可以提升咱們工做效率的一些插件。你能夠在個人公衆號下面回覆「Settings」，提早拿到個人Android Studio的配置導入到本身的Android Studio裏瞭解一下！