1. 程式人生 > >Git學習之Git模型

Git學習之Git模型

1 Git簡介

Git 是一個分散式版本控制工具(便於程式碼儲存,追蹤程式碼的修改和程式碼回退),它的作者開發了Linux的 Linus Torvalds ,git目前在版本管理中應用十分普遍,本篇文章來自https://nvie.com/posts/a-successful-git-branching-model/ 和自己的理解。
git和其他版本管理工具的區別:

學過git的一定對這張圖很熟悉,我曾經看這張圖看的很吃力,現在總算能簡單理解這張圖,由於每個公司git使用方式都存在區別,我會按照自己的理解講述這git模型圖。
在這裡插入圖片描述

2 兩個主要的分支

git分支模型中至少會有兩個分支,master和develop,這兩個分支是一直存在的,不會被刪除。
master:


master分支對應線上版本,也就是已釋出到app store的版本,是穩定的上線版本,總是和線上正執行的版本對應,每一次更新,最好新增對應的版本號標籤(TAG)便於定位到特定釋出版本。hotfix之後merge程式碼也需要新增tag。

develop:
develop分支對應開發分支,版本release之前的分支,平時開發工作都是在這個分支上,git中的HEAD也一般指向這個分支。

3 其他暫時(會被刪除)分支

Feature branches: 具體到每個feature(功能分支,一個獨立完整地功能)
Release branches: develop 分支被稱為β版本,用於輔助版本釋出。
**Hotfix branches:**線上版本有問題會建立Hotfix 分支進行修復

3.1 Feature branches

功能分支初始從develop分支拉取,通常是下一版(或者未來版本)開發新的功能的分支。功能分支是隻要這個功能處於開發狀態它就會存在,但確定開發完成並且開發的功能會被包含到下一次釋出的版本最終會被合併到develop分支,如果不需要則可以刪除。
舉個例子:一個新聞app,已經做了好幾個版本,最新一個版本要包含新聞查詢功能,這個查詢功能就可以最為一個feature。

app的某個版本可能需要開發多個新功能,所以可能會有多個feature,或者多個feature並行開發。
在這裡插入圖片描述
注意:
並不是所有的feature都會被合併到develop,有很多feature是試驗性質的,或者做出來的效果不太好,就可能會被拋棄。

3.2 Release branches

Release branches:
Release分支是為新版本的釋出做準備的,允許我們在最後時刻做一些細小的修改,類似(程式碼格式修改,程式碼小bug修改,版本號,開發時間修改等等)。Release分支一般從develop分支拉取,最終會合併到develop和master分支上(一定是兩個),它的習慣命名方式為:release-*,這個新分支可能會存在一段時間,直到該發行版到達它的預定目標。

Release 分支的建立
當develop分支上的程式碼已經包含了所有即將釋出的版本中所計劃包含的軟體功能(不能包含將來要釋出的功能),並且已通過所有測試時,我們就可以考慮準備建立release分支了。
建立release分支,並被賦予版本號之後,develop分支就可以為“下一個版本”服務了。當一個release分支準備好成為一個真正的發行版的時候,還有一些問題需要完成,首先,release分支要合併到master上(記錄發行版),然後,提交到master上必須打一個標籤,以便以後更加方便的引用這個歷史版本,最後,在release分支上的修改必須合併到develop分支上,以便未來發行版也包含這些bugs的修復(很重要,要把release上的修改合併到develop上)。

開發過程中可能有很多的測試apk版本,這裡給出我們公司的規定:
Develop branch: related with the version that ready to test internal (Alpha version)對應α版本。
Release branch: related with the version that ready to release (Beta version)對應β版本。
注意:
注意release修復一些問題之後不但要合併到master還要合併到develop,這樣再從develop拉取程式碼都是最新的。

4 熱修復(hot fix)

熱修復:已經上線的版本,忽然發現了一個影響使用者使用的bug,需要進行修復。
hotfix一般從master分支派生,最終必須合併回master分支和develop分支,分支命名慣例:hotfix-*。
在這裡插入圖片描述
修復bug的過程:
從master拉取程式碼建立hotfix,然後修復bug,hotfix會被合併到master分支上,同時還需要合併到develop分支上,確保以後從develop拉取分支不會受以上bug的影響。

注意:
修復hotfix分支存在的bug後生成的apk就可以用於發版了,為什麼此時需要把程式碼合併到master分支,為什麼不等到最終develop merge到master(hotfix程式碼會被合併到develop上),因為master branch 必須和當前上線版本一致。

奉上一些微軟的git規範:
• Master branch: related with the last release function
• Hotfix branch: to mitigate live site issue.
○ pull from master branch
○ push back to master branch when finish hotfix
○ Merge to develop branch if there is any code change
• Develop branch: related with the version that ready to test internal (Alpha version)
• Release branch: related with the version that ready to release (Beta version)
○ According to requirement that want to release, select change set to pull from Develop branch
○ Push to master branch with tag after bug fix
○ Push back to develop branch after release
• Feature branch: related with function, there are several feature branch, so name it like this: feature/xxxxx
○ Pull from develop branch when start a new feature
○ Push back to develop branch after finishing the feature
○ Delete this feature branch after finishing
• Dev branch: dev works on this, the purpose is to send pull request when you finish feature or bug fix, name it like this: dev//
○ Pull from develop branch or feature branch
○ Push back to feature branch