Git工程開發實踐（四）——Git分支管理策略

Git工程開發實踐（四）——Git分支管理策略

1、Git版本管理的挑戰

Git是很是優秀的版本管理工具，但面對版本管理依然有很是大得挑戰。工程開發中，開發者彼此的代碼協做必然帶來不少問題和挑戰：
A、如何開始一個Feature開發，而不影響其它Feature？
B、因爲很容易建立新分支，分支多瞭如何管理，時間久了，如何知道每一個分支是幹什麼的？
C、哪些分支已經合併回了主幹？
D、如何進行Release的管理？開始一個Release的時候如何凍結Feature, 如何在Prepare Release的時候，開發人員能夠繼續開發新的功能？
E、生產線上代碼出現Bug，如何快速修復？並且修復的代碼要包含到開發人員的分支以及下一個Release?
大部分開發人員使用Git通常使用三個甚至兩個分支，一個是Master，一個是Develop，還有一個基於Develop的各類分支。在項目規模小的時候勉強能夠支撐，但若是開發人員較多，並且項目週期過長就會出現各類問題。
在Git進行源碼管理實踐中，誕生了Git Flow，用於進行Git分支管理。

2、主流分支策略簡介

Git主流分支策略有三種：Git Flow、GitHub Flow、TBD。
Git Flow是應用最廣的Git分支管理實踐。
GitHub Flow主要應用於GitHub代碼託管工具中。
https://guides.github.com/introduction/flow/
Trunk based development
TBD（Trunk-based development），是單主幹的分支實踐，在SVN 中比較流行。
https://trunkbaseddevelopment.com/alternative-branching-models/
每一個開發團隊都應該根據團隊自身和項目的特色來選擇最適合的分支實踐。首先是項目的版本發佈週期。若是發佈週期較長，則Git-Flow是最好的選擇。Git-Flow能夠很好地解決新功能開發、版本發佈、生產系統維護等問題；若是發佈週期較短，則TBD和GitHub Flow都是不錯的選擇。GitHub Flow的特點在於集成了Pull Request和代碼審查。若是項目已經使用GitHub，則GitHub Flow是最佳的選擇。GitHub Flow和TBD對持續集成和自動化測試等基礎設施有比較高的要求。

3、Git Flow簡介

Git Flow是構建在Git上的一個組織軟件開發活動的源碼管理的模型，是一套使用Git進行源代碼管理時的行爲規範和簡化部分Git操做的工具，是在Git上構建的一項源碼管理最佳實踐。
Git Flow經過利用Git建立和管理分支的能力，爲每一個分支設定具備特定的含義名稱，並將軟件生命週期中的各種活動歸併到不一樣的分支上，實現了軟件開發過程不一樣操做的相互隔離。
軟件開發模型常見的有瀑布模型、迭×××發模型、敏捷開發模型等不一樣的模型，每種模型有各自應用場景。Git Flow重點解決的是因爲源代碼在開發過程當中的各類衝突致使開發活動混亂的問題。所以，Git flow能夠很好的與各類現有開發模型結合使用。
Git Flow分支模型資料以下：
https://nvie.com/posts/a-successful-git-branching-model/

4、Git Flow模型簡介

一、Git Flow模型簡介

Git Flow模型中定義了主分支和輔助分支兩類分支，其中主分支用於組織與軟件開發、部署相關的活動；輔助分支組織用於解決特定的問題而進行的各類開發活動。

二、主分支

主分支是全部開發活動的核心分支。全部的開發活動產生的輸出物最終都會反映到主分支的代碼中。主分支分爲master分支和develop分支。

A、master分支
一般，master分支只能從其它分支合併，不能在master分支直接修改。master分支上存放的是隨時可供在生產環境中部署的代碼（Production Ready state）。當開發活動到必定階段，產生一份新的可供部署的代碼時，master分支上的代碼會被更新。同時，每一次更新，最好添加對應的版本號標籤（TAG）。
全部在Master分支上的Commit應該打Tag。
B、develop分支
a、develop分支是保持當前開發最新成果的分支，通常會在此分支上進行晚間構建(Nightly Build)並執行自動化測試。
b、develop分支產生於master分支, 並長期存在。
c、當一個版本功能開發完畢且經過測試功能穩定時，就會合併到master分支上，並打好帶有相應版本號的tag。
d、develop分支通常命名爲develop
develop分支是主開發分支，包含全部要發佈到下一個Release的代碼，主要合併其它分支，好比Feature分支。

三、輔助分支

輔助分支是用於組織解決特定問題的各類軟件開發活動的分支。輔助分支主要用於組織軟件新功能的並行開發、簡化新功能開發代碼的跟蹤、輔助完成版本發佈工做以及對生產代碼的缺陷進行緊急修復工做。輔助分支一般只會在有限的時間範圍內存在。
輔助分支包括用於開發新功能時所使用的feature分支，用於輔助版本發佈的release分支，用於修正生產代碼中的缺陷的hotfix分支。
輔助分支都有固定的使用目的和分支操做限制。經過對分支的命名，定義了使用輔助分支的方法。
A、feature分支
feature分支使用規範：
a、能夠從develop分支發起feature分支。
b、代碼必須合併回develop分支。
c、feature分支的命名可使用除master，develop，release-*，hotfix-*以外的任何名稱。
feature分支（topic分支）一般在開發一項新的軟件功能的時候使用，分支上的代碼變動最終合併回develop分支或者乾脆被拋棄掉（例如實驗性且效果很差的代碼變動）。
通常而言，feature分支代碼能夠保存在開發者本身的代碼庫中而不強制提交到主代碼庫裏。
Feature分支開發完成後，必須合併回Develop分支，合併完分支後通常會刪Feature分支，但也能夠保留。

B、release分支
release分支使用規範：
a、能夠從develop分支派生；
b、必須合併回develop分支和master分支；
c、分支命名慣例：release-*；
release分支是爲發佈新的產品版本而設計的。在release分支上的代碼容許作測試、bug修改、準備發佈版本所需的各項說明信息（版本號、發佈時間、編譯時間等）。經過在release分支上進行發佈相關工做可讓develop分支空閒出來以接受新的feature分支上的代碼提交，進入新的軟件開發迭代週期。
當develop分支上的代碼已經包含了全部即將發佈的版本中所計劃包含的軟件功能，而且已經過全部測試時，能夠考慮準備建立release分支。而全部在當前即將發佈的版本外的業務需求必定要確保不能混到release分支內（避免由此引入一些不可控的系統缺陷）。
成功的派生release分支並被賦予版本號後，develop分支就能夠爲下一個版本服務。版本號的命名能夠依據項目定義的版本號命名規則進行。
發佈Release分支時，合併Release到Master和Develop， 同時在Master分支上打個Tag記住Release版本號，而後就能夠刪除Release分支。

C、hotfix分支
hotfix分支使用規範：
a、能夠從master分支派生；
b、必須合併回master分支和develop分支；
c、分支命名慣例：hotfix-*；
hotfix分支是計劃外建立的，能夠產生一個新的可供在生產環境部署的軟件版本。
當生產環境中的軟件遇到異常狀況或者發現了嚴重到必須當即修復的軟件缺陷時，就須要從master分支上指定的TAG版本派生hotfix分支來組織代碼的緊急修復工做。優勢是不會打斷正在進行的develop分支的開發工做，可以讓團隊中負責新功能開發的人與負責代碼緊急修復的人並行的開展工做。
hotfix分支基於Master分支建立，開發完後須要合併回Master和Develop分支，同時在Master上打一個tag。

5、Git Flow工程實踐的意義

Git Flow開發模型從源代碼管理角度對一般意義上的軟件開發活動進行了約束，爲軟件開發提供了一個可供參考的管理模型。Git Flow開發模型讓代碼倉庫保持整潔，讓小組各個成員之間的開發相互隔離，可以有效避免處於開發狀態中的代碼相互影響而致使的效率低下和混亂。
爲了簡化使用Git Flow模型時Git指令的複雜性，nvie開發出了一套git加強指令集，能夠運行於Windows、Linux、Unix和Mac操做系統下。
https://github.com/nvie/gitflow
Git Flow工具是一套工具命令集，是對Git命令的封裝，其命令以下：

git flow init 
git flow feature start xxx 
git flow feature finish xxx 
git flow release start 0.1.xx 
git flow release finish 0.1.xx 
git flow hotfix start xxx 
git flow hotfix finish xxx

使用Git Flow工具只須要兩個命令便可完成Git Flow分支管理。若是使用Git命令，對開發者來講足夠繁瑣。

6、Git Flow分支管理應用示例

一、建立develop分支

git branch develop
git push -u origin develop

二、開始新Feature開發

git checkout -b some-feature develop
# Optionally, push branch to origin:
git push -u origin some-feature       
git status
git add some-file
git commit

三、完成Feature

git pull origin develop
git checkout develop
git merge --no-ff some-feature
git push origin develop
git branch -d some-feature
git push origin --delete some-feature

四、開始Release

git checkout -b release-0.1.0 develop
# Optional: Bump version number, commit
# Prepare release, commit

五、完成Release

git checkout master
git merge --no-ff release-0.1.0
git push
git checkout develop
git merge --no-ff release-0.1.0
git push
git branch -d release-0.1.0
# If you pushed branch to origin:
git push origin --delete release-0.1.0   
git tag -a v0.1.0 master
git push --tags

六、開始Hotfix

git checkout -b hotfix-0.1.1 master

七、完成Hotfix

git checkout master
git merge --no-ff hotfix-0.1.1
git push
git checkout develop
git merge --no-ff hotfix-0.1.1
git push
git branch -d hotfix-0.1.1
git tag -a v0.1.1 master
git push --tags