目錄

?

一、Git版本管理的挑戰(zhàn)

二、主流分支策略簡介

三、Git Flow簡介

四、Git Flow模型簡介

1、Git Flow模型簡介

2、初始化主分支、創(chuàng)建 develop 分支

A、master分支

B、develop分支

3、輔助分支

A、feature分支

B、release分支

C、緊急維護(hù)分支 Hotfix

五、Git Flow工程實(shí)踐的意義

六、Git Flow分支管理應(yīng)用示例

1、創(chuàng)建develop分支

2、開始新Feature開發(fā)

3、完成Feature

4、開始Release

5、完成Release

6、開始Hotfix

7、完成Hotfix

七、Git提交日志規(guī)范

1、Git提交日志模板

2、Git提交日志模板設(shè)置

3、Git提交日志填寫

---

?

一、Git版本管理的挑戰(zhàn)

Git是非常優(yōu)秀版本管理工具，但面對(duì)版本管理依然有非常大得挑戰(zhàn)。

工程開發(fā)中，開發(fā)者彼此的代碼協(xié)作必然帶來很多問題和挑戰(zhàn)：

• 1、如何開始一個(gè)Feature的開發(fā)，而不影響別的Feature？
• 2、由于很容易創(chuàng)建新分支，分支多了如何管理，時(shí)間久了，如何知道每個(gè)分支是干什么的？
• 3、哪些分支已經(jīng)合并回了主干？
• 4、如何進(jìn)行Release的管理？開始一個(gè)Release的時(shí)候如何凍結(jié)Feature, 如何在Prepare Release的時(shí)候，開發(fā)人員可以繼續(xù)開發(fā)新的功能？
• 5、線上代碼出Bug了，如何快速修復(fù)？而且修復(fù)的代碼要包含到開發(fā)人員的分支以及下一個(gè)Release?

?

大部分開發(fā)人員使用Git一般使用三個(gè)甚至兩個(gè)分支，一個(gè)是Master，一個(gè)是Develop，還有一個(gè)基于Develop的各種分支。在項(xiàng)目規(guī)模小的時(shí)候勉強(qiáng)可以支撐，但如果開發(fā)人員較多，而且項(xiàng)目周期過長就會(huì)出現(xiàn)各種問題。
在Git進(jìn)行源碼管理實(shí)踐中，誕生了Git Flow，用于進(jìn)行Git分支管理。

二、主流分支策略簡介

Git主流分支策略有三種：Git Flow、GitHub Flow、TBD。
Git Flow是應(yīng)用最廣的Git分支管理實(shí)踐。
GitHub Flow主要應(yīng)用于GitHub代碼托管工具中。
https://guides.github.com/introduction/flow/
Trunk based development
TBD（Trunk-based development），是單主干的分支實(shí)踐，在SVN 中比較流行。
https://trunkbaseddevelopment.com/alternative-branching-models/
每個(gè)開發(fā)團(tuán)隊(duì)都應(yīng)該根據(jù)團(tuán)隊(duì)自身和項(xiàng)目的特點(diǎn)來選擇最適合的分支實(shí)踐。首先是項(xiàng)目的版本發(fā)布周期。如果發(fā)布周期較長，則Git-Flow是最好的選擇。Git-Flow可以很好地解決新功能開發(fā)、版本發(fā)布、生產(chǎn)系統(tǒng)維護(hù)等問題；如果發(fā)布周期較短，則TBD和GitHub Flow都是不錯(cuò)的選擇。GitHub Flow的特色在于集成了Pull Request和代碼審查。如果項(xiàng)目已經(jīng)使用GitHub，則GitHub Flow是最佳的選擇。GitHub Flow和TBD對(duì)持續(xù)集成和自動(dòng)化測試等基礎(chǔ)設(shè)施有比較高的要求。

三、Git Flow簡介

Git Flow是構(gòu)建在Git上的一個(gè)組織軟件開發(fā)活動(dòng)的源碼管理的模型，是一套使用Git進(jìn)行源代碼管理時(shí)的行為規(guī)范和簡化部分Git操作的工具，是在Git上構(gòu)建的一項(xiàng)源碼管理最佳實(shí)踐。
Git Flow通過利用Git創(chuàng)建和管理分支的能力，為每個(gè)分支設(shè)定具有特定的含義名稱，并將軟件生命周期中的各類活動(dòng)歸并到不同的分支上，實(shí)現(xiàn)了軟件開發(fā)過程不同操作的相互隔離。
軟件開發(fā)模型常見的有瀑布模型、迭×××發(fā)模型、敏捷開發(fā)模型等不同的模型，每種模型有各自應(yīng)用場景。Git Flow重點(diǎn)解決的是由于源代碼在開發(fā)過程中的各種沖突導(dǎo)致開發(fā)活動(dòng)混亂的問題。因此，Git flow可以很好的與各種現(xiàn)有開發(fā)模型結(jié)合使用。
Git Flow分支模型資料如下：
https://nvie.com/posts/a-successful-git-branching-model/

四、Git Flow模型簡介

1、Git Flow模型簡介

Git Flow模型中定義了主分支和輔助分支兩類分支，其中主分支用于組織與軟件開發(fā)、部署相關(guān)的活動(dòng)；輔助分支組織用于解決特定的問題而進(jìn)行的各種開發(fā)活動(dòng)。

?

2、初始化主分支、創(chuàng)建 develop 分支

主分支是所有開發(fā)活動(dòng)的核心分支。所有的開發(fā)活動(dòng)產(chǎn)生的輸出物最終都會(huì)反映到主分支的代碼中。主分支分為master分支和develop分支。

?

A、master分支

通常，master分支只能從其它分支合并，不能在master分支直接修改。master分支上存放的是隨時(shí)可供在生產(chǎn)環(huán)境中部署的代碼（Production Ready state）。當(dāng)開發(fā)活動(dòng)到一定階段，產(chǎn)生一份新的可供部署的代碼時(shí)，master分支上的代碼會(huì)被更新。同時(shí)，每一次更新，最好添加對(duì)應(yīng)的版本號(hào)標(biāo)簽（TAG）。
所有在Master分支上的Commit應(yīng)該打Tag。

B、develop分支

develop分支是保持當(dāng)前開發(fā)最新成果的分支，一般會(huì)在此分支上進(jìn)行晚間構(gòu)建(Nightly Build)并執(zhí)行自動(dòng)化測試。?

develop分支產(chǎn)生于master分支, 并長期存在。

當(dāng)一個(gè)版本功能開發(fā)完畢且通過測試功能穩(wěn)定時(shí)，就會(huì)合并到master分支上，并打好帶有相應(yīng)版本號(hào)的tag。

develop分支一般命名為develop

develop分支是主開發(fā)分支，包含所有要發(fā)布到下一個(gè)Release的代碼，主要合并其它分支，比如Feature分支。

?

這樣兩個(gè)分支開發(fā)會(huì)出現(xiàn)一些問題:

a) develop 分支只有發(fā)布完了才能進(jìn)行下一個(gè)版本開發(fā)，開發(fā)會(huì)比較緩慢。

b) 線上代碼出現(xiàn) bug 如何進(jìn)行 bug 修復(fù)

?

3、輔助分支

輔助分支是用于組織解決特定問題的各種軟件開發(fā)活動(dòng)的分支。輔助分支主要用于組織軟件新功能的并行開發(fā)、簡化新功能開發(fā)代碼的跟蹤、輔助完成版本發(fā)布工作以及對(duì)生產(chǎn)代碼的缺陷進(jìn)行緊急修復(fù)工作。輔助分支通常只會(huì)在有限的時(shí)間范圍內(nèi)存在。
輔助分支包括用于開發(fā)新功能時(shí)所使用的feature分支，用于輔助版本發(fā)布的release分支，用于修正生產(chǎn)代碼中的缺陷的hotfix分支。
輔助分支都有固定的使用目的和分支操作限制。通過對(duì)分支的命名，定義了使用輔助分支的方法。

A、feature分支

feature 分支用來開發(fā)具體的功能，一般 fork 自 develop 分支，最終可能會(huì)合并到 develop 分支。比如我們要在下一個(gè)版本增加功能1、功能2、功能3。那么我們就可以起三個(gè)feature 分支：feature1，feature2，feature3。（feature 分支命名最好能夠自解釋，這并不是一種好的命名。）隨著我們開發(fā)，功能1和功能2都被完成了，而功能3因?yàn)槟承┰蛲瓿刹涣?#xff0c;那么最終 feature1 和 feature2 分支將被合并到 develop 分支，而 feature3 分支將被干掉。

feature分支使用規(guī)范：
a、可以從develop分支發(fā)起feature分支。
b、代碼必須合并回develop分支。
c、feature分支的命名可以使用除master，develop，release-*，hotfix-*之外的任何名稱。
feature分支（topic分支）通常在開發(fā)一項(xiàng)新的軟件功能的時(shí)候使用，分支上的代碼變更最終合并回develop分支或者干脆被拋棄掉（例如實(shí)驗(yàn)性且效果不好的代碼變更）。
一般而言，feature分支代碼可以保存在開發(fā)者自己的代碼庫中而不強(qiáng)制提交到主代碼庫里。
Feature分支開發(fā)完成后，必須合并回Develop分支，合并完分支后一般會(huì)刪Feature分支，但也可以保留。

從 develop 分支建一個(gè) feature 分支，并切換到 feature 分支.

git checkout -b some-feature develop // Optionally, push branch to origin: git push -u origin some-feature // 做一些改動(dòng) git status git add some-file git commit

開發(fā)完成后 feature 合并到 develop 分支

git pull origin develop git checkout develop git merge --no-ff some-feature git push origin develop git branch -d some-feature //If you pushed branch to origin: git push origin --delete some-feature

上面我們 merge 分支的時(shí)候使用了參數(shù) --no-ff，ff 是fast-forward 的意思，--no-ff就是禁用fast-forward。關(guān)于這兩種模式的區(qū)別如下圖。（可以使用 sourceTree 或者命令git log --graph查看。）

看了上面的圖，那么使用非fast-forward模式來 merge 的好處就不言而喻了：我們知道哪些 commit 是某些 feature 相關(guān)的。雖然 git merge 的時(shí)候會(huì)自動(dòng)判斷是否使用fast-farward模式，但是有時(shí)候?yàn)榱烁鞔_，我們還是要加參數(shù)--no-ff或者--ff。

B、release分支

Release分支基于Develop分支創(chuàng)建，打完Release分之后，我們可以在這個(gè)Release分支上測試，修改Bug等。同時(shí)，其它開發(fā)人員可以基于開發(fā)新的Feature (記住：一旦打了Release分支之后不要從Develop分支上合并新的改動(dòng)到Release分支)

release 分支是 pre-master。release 分支從 develop 分支 fork 出來，最終會(huì)合并到 develop 分支和 master 分支。合并到 master 分支上就是可以發(fā)布的代碼了。有人可能會(huì)問那為什么合并回 develop 分支呢？很簡單，有了 release 分支，那么相關(guān)的代碼修復(fù)就只會(huì)在 release 分支上改動(dòng)了，最后必然要合并到 develop 分支。

release分支使用規(guī)范：
a、可以從develop分支派生；
b、必須合并回develop分支和master分支；
c、分支命名慣例：release-*；

release分支是為發(fā)布新的產(chǎn)品版本而設(shè)計(jì)的。在release分支上的代碼允許做測試、bug修改、準(zhǔn)備發(fā)布版本所需的各項(xiàng)說明信息（版本號(hào)、發(fā)布時(shí)間、編譯時(shí)間等）。通過在release分支上進(jìn)行發(fā)布相關(guān)工作可以讓develop分支空閑出來以接受新的feature分支上的代碼提交，進(jìn)入新的軟件開發(fā)迭代周期。
當(dāng)develop分支上的代碼已經(jīng)包含了所有即將發(fā)布的版本中所計(jì)劃包含的軟件功能，并且已通過所有測試時(shí)，可以考慮準(zhǔn)備創(chuàng)建release分支。而所有在當(dāng)前即將發(fā)布的版本外的業(yè)務(wù)需求一定要確保不能混到release分支內(nèi)（避免由此引入一些不可控的系統(tǒng)缺陷）。
成功的派生release分支并被賦予版本號(hào)后，develop分支就可以為下一個(gè)版本服務(wù)。版本號(hào)的命名可以依據(jù)項(xiàng)目定義的版本號(hào)命名規(guī)則進(jìn)行。
發(fā)布Release分支時(shí)，合并Release到Master和Develop， 同時(shí)在Master分支上打個(gè)Tag記住Release版本號(hào)，然后就可以刪除Release分支。
?

創(chuàng)建release分支

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

release分支測試完成

============測試完成后，release 合并到 master=========== git checkout master git merge --no-ff release-0.1.0 git push ============測試完成后，release 合并到 develop =========== git checkout develop git merge --no-ff release-0.1.0 git push =============刪除 release分支 ============================ git branch -d release-0.1.0 //If you pushed branch to origin: git push origin --delete release-0.1.0 =============在master分支基礎(chǔ)上打tag==================== git tag -a v0.1.0 master git push --tags

C、緊急維護(hù)分支 Hotfix

顧名思義，hotfix 分支用來修復(fù)線上 bug。當(dāng)線上代碼出現(xiàn) bug 時(shí)，我們基于 master 分支開一個(gè) hotfix 分支，修復(fù) bug 之后再將 hotfix 分支合并到 master 分支并進(jìn)行發(fā)布，同時(shí) develop 分支作為最新最全的代碼分支，hotfix 分支也需要合并到 develop 分支上去。仔細(xì)想一想，其實(shí) hotfix 分支和 release 分支功能類似。hotfix 的好處是不打斷 develop 分支正常進(jìn)行，同時(shí)對(duì)于現(xiàn)實(shí)代碼的修復(fù)貌似也沒有更好的方法了（總不能直接修改 master 代碼）。

hotfix分支使用規(guī)范：
a、可以從master分支派生；
b、必須合并回master分支和develop分支；
c、分支命名慣例：hotfix-*；

hotfix分支是計(jì)劃外創(chuàng)建的，可以產(chǎn)生一個(gè)新的可供在生產(chǎn)環(huán)境部署的軟件版本。
當(dāng)生產(chǎn)環(huán)境中的軟件遇到異常情況或者發(fā)現(xiàn)了嚴(yán)重到必須立即修復(fù)的軟件缺陷時(shí)，就需要從master分支上指定的TAG版本派生hotfix分支來組織代碼的緊急修復(fù)工作。優(yōu)點(diǎn)是不會(huì)打斷正在進(jìn)行的develop分支的開發(fā)工作，能夠讓團(tuán)隊(duì)中負(fù)責(zé)新功能開發(fā)的人與負(fù)責(zé)代碼緊急修復(fù)的人并行的開展工作。
hotfix分支基于Master分支創(chuàng)建，開發(fā)完后需要合并回Master和Develop分支，同時(shí)在Master上打一個(gè)tag。

創(chuàng)建Hotfix分支

git checkout -b hotfix-0.1.1 master

Hotfix分支修復(fù)完成

============buf fix 之后，hotfix 合并到 master=========== git checkout master git merge --no-ff hotfix-0.1.1 git push ============buf fix 之后，hotfix 合并到 develop ========= git checkout develop git merge --no-ff hotfix-0.1.1 git push =============刪除 hotfix分支 ============================ git branch -d hotfix-0.1.1 =============在master分支基礎(chǔ)上打tag====================== git tag -a v0.1.1 master git push --tags

?

五、Git Flow工程實(shí)踐的意義

Git Flow開發(fā)模型從源代碼管理角度對(duì)通常意義上的軟件開發(fā)活動(dòng)進(jìn)行了約束，為軟件開發(fā)提供了一個(gè)可供參考的管理模型。Git Flow開發(fā)模型讓代碼倉庫保持整潔，讓小組各個(gè)成員之間的開發(fā)相互隔離，能夠有效避免處于開發(fā)狀態(tài)中的代碼相互影響而導(dǎo)致的效率低下和混亂。
為了簡化使用Git Flow模型時(shí)Git指令的復(fù)雜性，nvie開發(fā)出了一套git增強(qiáng)指令集，可以運(yùn)行于Windows、Linux、Unix和Mac操作系統(tǒng)下。
https://github.com/nvie/gitflow
Git Flow工具是一套工具命令集，是對(duì)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工具只需要兩個(gè)命令即可完成Git Flow分支管理。如果使用Git命令，對(duì)開發(fā)者來說足夠繁瑣。

?

六、Git Flow分支管理應(yīng)用示例

1、創(chuàng)建develop分支

git branch develop git push -u origin develop

2、開始新Feature開發(fā)

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

3、完成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

4、開始Release

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

5、完成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

6、開始Hotfix

git checkout -b hotfix-0.1.1 master

7、完成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

?

七、Git提交日志規(guī)范

1、Git提交日志模板

Git支持對(duì)每次提交的日志信息進(jìn)行規(guī)范，可以通過設(shè)置提交模板實(shí)現(xiàn)。
建立一個(gè)gitCommitTemplate文件，內(nèi)容為：

#commit message包含三部分，header, body和footer，其中header必選，body和footer可選。 # type(<scope>): <subject>#<body>#<footer>#type字段包含：# feature:新功能開發(fā)# update:功能修改# bugfix：bug修復(fù)# refactor：重構(gòu)（非新增功能、非bug修復(fù)）# docs：文檔（documentation）# style：格式（不影響代碼運(yùn)行的變動(dòng)）# test：增加測試# chore：構(gòu)建過程或輔助工具的變動(dòng)#scope用于說明commit影響的范圍，比如數(shù)據(jù)層、控制層、視圖層等等，不同項(xiàng)目不同。#subject是commit目的的簡短描述，不超過50個(gè)字符。#以動(dòng)詞開頭，使用第一人稱現(xiàn)在時(shí)，比如change，而不是changed或changes。#第一個(gè)字母小寫。#結(jié)尾不加句號(hào)（.）。#body部分是對(duì)本次commit的詳細(xì)描述，可以分成多行。#使用第一人稱現(xiàn)在時(shí)，比如使用change而不是changed或changes。#應(yīng)該說明代碼變動(dòng)的動(dòng)機(jī)以及與以前行為的對(duì)比。#footer#A、如果當(dāng)前代碼與上一個(gè)版本不兼容，則footer部分以BREAKING CHANGE開頭， # 后跟對(duì)變動(dòng)的描述、變動(dòng)理由以及遷移方法。#B、關(guān)閉Issue,關(guān)閉某個(gè)issue可以：close #issue_id，多個(gè)使用逗號(hào)分隔

?Revert撤銷操作
如果當(dāng)前commit用于撤銷以前的commit，則必須以revert:開頭，后面跟著被撤銷Commit的Header。

revert: feat(pencil): add 'graphiteWidth' option This reverts commit 667ecc1654a317a13331b17617d973392f415f02.

Body部分的格式是固定的，必須寫成?This?reverts commit?commit_id.?，其中的hash是被撤銷commit的?SHA?標(biāo)識(shí)符?。 如果當(dāng)前commit與被撤銷的commit，在同一個(gè)發(fā)布（release）里面， 那么都不會(huì)出現(xiàn)在Change log 里面。如果兩者在不同的發(fā)布，那么當(dāng)前commit，會(huì)出現(xiàn)在Change log的Reverts小標(biāo)題下面。

2、Git提交日志模板設(shè)置

設(shè)置當(dāng)前分支的提交模板

git config commit.template [模板文件名] git config commit.template gitcommit_template

設(shè)置全局的提交模板

git config --global commit.template [模板文件名] git config --global commit.template gitcommit_template

設(shè)置文本編輯器

git config --global core.editor [編輯器名稱] git config --global core.editor vim

3、Git提交日志填寫

使用git commit -a提交時(shí)，Git會(huì)用設(shè)置的編輯器打開設(shè)置的提交日志模板，然后按照格式添加相應(yīng)的備注，保存提交到遠(yuǎn)程分支。

?

參考：
https://www.jianshu.com/p/43302a72c399

https://blog.51cto.com/9291927/2172459

總結(jié)

以上是生活随笔為你收集整理的Git工程开发实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。