【Git原理與使用】-- 企業(yè)級開發(fā)模型

這篇具有很好參考價(jià)值的文章主要介紹了【Git原理與使用】-- 企業(yè)級開發(fā)模型。希望對大家有所幫助。如果存在錯誤或未考慮完全的地方，請大家不吝賜教，您也可以點(diǎn)擊"舉報(bào)違法"按鈕提交疑問。

引入

系統(tǒng)開發(fā)環(huán)境

Git 分支設(shè)計(jì)規(guī)范

master 分支

release 分支

develop 分支

feature 分支

hotfix 分支

開發(fā)場景 - 基于git flow模型的實(shí)踐

DevOps研發(fā)平臺

修復(fù)測試環(huán)境 Bug

修改預(yù)發(fā)布環(huán)境 Bug

修改正式環(huán)境 Bug

緊急修復(fù)正式環(huán)境 Bug

拓展實(shí)踐

都說：對于開發(fā)者，Git是非常的重要的，但是為什么呢？這就需要從企業(yè)級的開發(fā)流程來說。

引入

????????我們知道，?個(gè)軟件從零開始到最終交付，?概包括以下?個(gè)階段：規(guī)劃、編碼、構(gòu)建、測試、發(fā)布、部署和維護(hù)。

????????最初，程序比較簡單，工作量不大，程序員?個(gè)人可以完成所有階段的工作。但隨著軟件產(chǎn)業(yè)的日益發(fā)展壯大，軟件的規(guī)模也在逐漸變得龐大。軟件的復(fù)雜度不斷攀升，?個(gè)人已經(jīng)hold不住了，就開始出現(xiàn)了精細(xì)化分工。

【Git原理與使用】-- 企業(yè)級開發(fā)模型,Git,git

但在傳統(tǒng)的 IT 組織下，開發(fā)團(tuán)隊(duì)(Dev)和運(yùn)維團(tuán)隊(duì)(Ops)之間訴求不同：

開發(fā)團(tuán)隊(duì)：(尤其是敏捷團(tuán)隊(duì))追求變化。
運(yùn)維團(tuán)隊(duì)：追求穩(wěn)定。

? ? ? ? 雙方往往存在利益的沖突。比如，精益和敏捷的團(tuán)隊(duì)把持續(xù)交付作為目標(biāo)，而運(yùn)維團(tuán)隊(duì)則為了線上的穩(wěn)定而強(qiáng)調(diào)變更控制。部門墻由此建立起來，這當(dāng)然不利于 IT 價(jià)值的最大化。

????????為了彌合開發(fā)和運(yùn)維之間的鴻溝，需要在文化、工具和實(shí)踐方面的系列變革 ??DevOps正式登上舞臺。

????????DevOps（Development和Operations的組合詞）是?種重視 “軟件開發(fā)?員（Dev）” 和 “IT運(yùn)維技術(shù)?員（Ops）” 之間溝通合作的文化、運(yùn)動或慣例。透過自動化 “軟件交付” 和 “架構(gòu)變更” 的流程，來使得構(gòu)建、測試、發(fā)布軟件能夠更加地快捷、頻繁和可靠。在 DevOps 的軟件開發(fā)過程包含計(jì)劃、編碼、構(gòu)建、測試、預(yù)發(fā)布、發(fā)布、運(yùn)維、監(jiān)控，由此可見 DevOps 的強(qiáng)大。

DevOps到底是什么意思？

? ? ? ? 與Git的關(guān)系，舉個(gè)例子：?個(gè)軟件的迭代，在我們開發(fā)人員看來，說白了就是對代碼進(jìn)行迭代，那么就需要對代碼進(jìn)行管理。也就是 Git（分布式版本控制系統(tǒng)），所以 Git 對于我們開發(fā)?員來說其重要性就不?而喻了。

系統(tǒng)開發(fā)環(huán)境

?歸正傳，對于開發(fā)人員來說，在系統(tǒng)開發(fā)過程中最常用的幾個(gè)環(huán)境必須要了解?下。

開發(fā)環(huán)境：開發(fā)環(huán)境是程序猿們專門用于日常開發(fā)的服務(wù)器。為了開發(fā)調(diào)試方便，?般打開全部錯誤報(bào)告和測試工具，是最基礎(chǔ)的環(huán)境。
測試環(huán)境：?個(gè)程序在測試環(huán)境工作不正常，那么肯定不能把它發(fā)布到生產(chǎn)機(jī)上。該環(huán)境是開發(fā)環(huán)境到生產(chǎn)環(huán)境的過渡環(huán)境。
預(yù)發(fā)布環(huán)境：該環(huán)境是為避免因測試環(huán)境和線上環(huán)境的差異等帶來的缺陷漏測而設(shè)立的?套環(huán)境。其配置等基本和?產(chǎn)環(huán)境?致，?的是能讓我們發(fā)正式環(huán)境時(shí)更有把握！所以預(yù)發(fā)布環(huán)境是你的產(chǎn)品質(zhì)量最后?道防線，因?yàn)橄?步你的項(xiàng)?就要上線了。要注意預(yù)發(fā)布環(huán)境服務(wù)器不在線上集成服務(wù)器范圍之內(nèi)，為單獨(dú)的?些機(jī)器。
生產(chǎn)環(huán)境：是指正式提供對外服務(wù)的線上環(huán)境，例如我們目前在移動端或PC端能訪問到的APP都是生產(chǎn)環(huán)境。

????????這幾個(gè)環(huán)境也可以說是系統(tǒng)開發(fā)的三個(gè)重要階段：開發(fā)->測試->上線。

【Git原理與使用】-- 企業(yè)級開發(fā)模型,Git,git

????????對于規(guī)模稍微大點(diǎn)的公司來說，可不止這么幾個(gè)環(huán)境，比如項(xiàng)目正式上線前還存在仿真 / 灰度環(huán)境（利用部分相對少量的用戶來測試），再比如還存在多套測試環(huán)境，以滿足不同版本上線前測試的需要。

?????????個(gè)項(xiàng)目的開始從設(shè)計(jì)開始，而?個(gè)項(xiàng)目的成功則從測試開始。?套良好的測試體系可以將系統(tǒng)中絕大部分的致命 Bug 解決在系統(tǒng)上線之前。測試系統(tǒng)的完善和成熟也是衡量?個(gè)軟件企業(yè)整體水平的重要指標(biāo)之一，測試往往被忽視，因?yàn)樗鼘梢缘碾[性、對軟件開發(fā)企業(yè)不產(chǎn)生直接的效益，但是它卻是軟件質(zhì)量的最終保障，乃至項(xiàng)目能否成功的重要因素！

Git 分支設(shè)計(jì)規(guī)范

????????環(huán)境有了概念后，那么對于開發(fā)人員來說，?般會針對不同的環(huán)境來設(shè)計(jì)分支。

分支	名稱	適用環(huán)境
master	主分支	生產(chǎn)環(huán)境
release	預(yù)發(fā)布分支	預(yù)發(fā)布 / 測試環(huán)境
develop	開發(fā)分支	開發(fā)環(huán)境
feature	需求開發(fā)分支	本地
hotfix	緊急修復(fù)分支	本地

注：以上表格中的分支和環(huán)境的搭配僅是常用的?種，可視情況而定不同的策略。

????????以上跟大家講解的是企業(yè)級常用的?種 Git 分支設(shè)計(jì)規(guī)范：Git Flow 模型。?

【Git原理與使用】-- 企業(yè)級開發(fā)模型,Git,git

master 分支

????????master 為主分支，該分支為只讀且唯一分支。用于部署到正式發(fā)布環(huán)境，?般由合并 release 分支得到。主分支作為穩(wěn)定的唯?代碼庫，任何情況下不允許直接在 master 分支上修改代碼。產(chǎn)品的功能全部實(shí)現(xiàn)后，最終在 master 分支對外發(fā)布，另外所有在 master 分支的推送應(yīng)該打標(biāo)簽（tag）做記錄，方便追溯。

????????master 分支不可刪除。

release 分支

????????release 為預(yù)發(fā)布分支，基于本次上線所有的 feature 分支合并到 develop 分支之后，基于 develop 分支創(chuàng)建?？梢圆渴鸬綔y試或預(yù)發(fā)布集群。命名以 release/ 開頭，建議的命名規(guī)則: release/version_publishtime 。release 分支主要用于提交給測試人員進(jìn)行功能測試。發(fā)布提測階段，會以 release 分支代碼為基準(zhǔn)進(jìn)行提測。如果在 release 分支測試出問題，需要回歸驗(yàn)證 develop 分支看否存在此問題。

????????release 分支屬于臨時(shí)分支，產(chǎn)品上線后可選刪除。

develop 分支

????????develop 為開發(fā)分支，基于 master 分支創(chuàng)建的只讀且唯一分支，始終保持最新完成以及 bug 修復(fù)后的代碼。可部署到開發(fā)環(huán)境對應(yīng)集群。

???????? 可根據(jù)需求大小程度確定是由 feature 分支合并。

feature 分支

????????feature 分支通常為新功能或新特性開發(fā)分支，以 develop 分支為基礎(chǔ)創(chuàng)建 feature 分支。命名以 feature/ 開頭，建議的命名規(guī)則： feature/user_createtime_feature 。新特性或新功能開發(fā)完成后，開發(fā)人員需合到 develop 分支。

? ? ? ? 一旦該需求發(fā)布上線，便將其刪除。

hotfix 分支

????????hotfix 分支為線上 bug 修復(fù)分支或叫補(bǔ)丁分支，主要用于對線上的版本進(jìn)行?bug 修復(fù)。當(dāng)線上出現(xiàn)緊急問題需要馬上修復(fù)時(shí)，需要基于 master 分支創(chuàng)建 hotfix 分支。命名以 hotfix/ 開頭，建議的命名規(guī)則: hotfix/user_createtime_hotfix 。

????????當(dāng)問題修復(fù)完成后，需要合并到 master 分支和 develop 分支并推送遠(yuǎn)程。?旦修復(fù)上線，便將其刪除。

開發(fā)場景 - 基于git flow模型的實(shí)踐

DevOps研發(fā)平臺

騰訊

阿里云

gitee

修復(fù)測試環(huán)境 Bug

????????在 develop 測試出現(xiàn)了Bug，建議直接在 feature 分支上進(jìn)行修復(fù)。修復(fù)后的提測上線流程與新需求加入的流程?致。

修改預(yù)發(fā)布環(huán)境 Bug

在 release 測試出現(xiàn)了 Bug，首先要回歸下 develop 分支是否同樣存在這個(gè)問題。

如果存在，修復(fù)流程與修復(fù)測試環(huán)境 Bug 流程?致。
如果不存在，這種可能性比較少，大部分是數(shù)據(jù)兼容問題，環(huán)境配置問題等。

修改正式環(huán)境 Bug

在 master 測試出現(xiàn)了Bug，首先要回歸下 release 和 develop 分支是否同樣存在這個(gè)問題。

如果存在，修復(fù)流程與修復(fù)測試環(huán)境 Bug 流程?致。
如果不存在，這種可能性也比較少，大部分是數(shù)據(jù)兼容問題，環(huán)境配置問題等。

緊急修復(fù)正式環(huán)境 Bug

????????需求在測試環(huán)節(jié)未測試出 Bug，上線運(yùn)行?段時(shí)候后出現(xiàn)了 Bug，需要緊急修復(fù)的。有的企業(yè)面對緊急修復(fù)時(shí)，支持不進(jìn)行測試環(huán)境的驗(yàn)證，但還是建議驗(yàn)證下預(yù)發(fā)布環(huán)境?？苫?master 創(chuàng)建 hotfix/xxx 分支，修復(fù)完畢后發(fā)布到 master 驗(yàn)證，驗(yàn)證完畢后，將 master 代碼合并到 develop 分支，同時(shí)刪掉 hotfix/xxx 分支。