柚子快報(bào)激活碼778899分享：初識(shí)git · 有關(guān)模型

http://yzkb.51969.com/

目錄

前言：

有關(guān)開發(fā)模型

前言：

其實(shí)文章更新到這里的時(shí)候，我們已經(jīng)學(xué)習(xí)了可以滿足我們?nèi)粘Ｉ钪械幕拘枨蟮闹噶盍?，但是為什么要更新本篇文章呢？是因?yàn)閷?shí)際生活中我們對(duì)于開發(fā)工作，運(yùn)維工作，以及測(cè)試工作都是由單獨(dú)的分支的，那么一個(gè)項(xiàng)目推進(jìn)的時(shí)候，整體的布局是什么樣的，不同的人應(yīng)該使用什么樣的分支，這是我們所關(guān)心的，自然就會(huì)涉及到很多不同的模型，所以本文主要是介紹有關(guān)模型的知識(shí)。

有關(guān)開發(fā)模型

我們了解開發(fā)模型之前，不妨簡(jiǎn)單回憶一下之前所涉及到的部分知識(shí)，比如master是用來干什么的，dev是用來干什么的，feature是用來干什么的等。

其實(shí)追其本源，都是從程序員的負(fù)責(zé)模塊引出來的。

比如開發(fā)者，涉及的工作部分肯定是規(guī)劃代碼，寫代碼，構(gòu)建代碼框架等，對(duì)于測(cè)試人員，涉及的工作肯定只有一個(gè)是測(cè)試，對(duì)于運(yùn)維工程師，涉及的工作內(nèi)容就是發(fā)布代碼，部署代碼，后期維護(hù)代碼等。

所以實(shí)際上的開發(fā)項(xiàng)目過程中，開發(fā)者們的分支一般都是dev分支，development，開發(fā)的意思，對(duì)于測(cè)試人員，涉及的部分是hotfix，也就是緊急修復(fù)分支的意思，對(duì)于運(yùn)維工程師，涉及的分支一般都是Release分支，也就是預(yù)發(fā)布分支，對(duì)于master分支來說，Release分支基本上就是發(fā)布之前的最后一道流程了，因?yàn)闀?huì)在該分支測(cè)試許多情況。

常見的比如仿真環(huán)境，模擬用戶真實(shí)使用的場(chǎng)景，然后在該分支上訪問代碼構(gòu)建的平臺(tái)，那么什么是灰度測(cè)試呢？灰度測(cè)試實(shí)際上是為了特殊的需求處理的，比如有部分人的環(huán)境并不是很符合該代碼構(gòu)建的平臺(tái)，但是勉強(qiáng)能用，所以為了該類用戶的需求，就會(huì)單獨(dú)為該類用戶測(cè)試。

這是涉及到的開發(fā)人員的職責(zé)。

所以環(huán)境一共分為：

開發(fā)環(huán)境，測(cè)試環(huán)境，預(yù)發(fā)布環(huán)境，生成環(huán)境。其中的生產(chǎn)環(huán)境就是面對(duì)用戶提供的線上服務(wù)平臺(tái)。

所以就會(huì)引發(fā)一個(gè)問題，對(duì)于開發(fā)人員來說，肯定是要敏捷度很高，畢竟需求那么多，所以代碼變化很大是正常的，對(duì)于運(yùn)維人員來說，肯定是不希望代碼變化的，也就是代碼穩(wěn)定了就先這樣的感覺。測(cè)試人員嘛，就，，，對(duì)吧哈哈哈哈。

言歸正抓，實(shí)際上的開發(fā)中如何平衡二者的關(guān)心呢？

此時(shí)DevOps就出場(chǎng)了，它本質(zhì)上更像是一種人人都清楚的慣例，而該詞語的組成是development operations的組成，開發(fā)和運(yùn)維之間的一種交流文化，詳細(xì)是什么就不是該文章的內(nèi)容了，這里放個(gè)鏈接，有興趣的可以自行查閱：

DevOps到底是什么意思？ - 知乎 (zhihu.com)

那么對(duì)于分支來說：

master 分?

? master 為主分?，該分?為只讀且唯?分?。?于部署到正式發(fā)布環(huán)境，?般由合并 release 分?得到。

? 主分?作為穩(wěn)定的唯?代碼庫,任何情況下不允許直接在 master 分?上修改代碼。 ? 產(chǎn)品的功能全部實(shí)現(xiàn)后，最終在master分?對(duì)外發(fā)布，另外所有在master分?的推送應(yīng)該打標(biāo)簽 （tag）做記錄，?便追溯。

? master 分?不可刪除。

release 分?

? release 為預(yù)發(fā)布分?，基于本次上線所有的 feature 分?合并到 develop 分?之后，基 于 develop 分?創(chuàng)建?？梢圆渴鸬綔y(cè)試或預(yù)發(fā)布集群。

? 命名以 release/ 開頭，建議的命名規(guī)則: release/version_publishtime 。

? release 分?主要?于提交給測(cè)試?員進(jìn)?功能測(cè)試。發(fā)布提測(cè)階段，會(huì)以 release 分?代碼 為基準(zhǔn)進(jìn)?提測(cè)。

? 如果在 release 分?測(cè)試出問題，需要回歸驗(yàn)證 develop 分?看否存在此問題。 ? release 分?屬于臨時(shí)分?，產(chǎn)品上線后可選刪除。

develop 分?

? develop 為開發(fā)分?，基于master分?創(chuàng)建的只讀且唯?分?，始終保持最新完成以及 bug 修 復(fù)后的代碼?？刹渴鸬介_發(fā)環(huán)境對(duì)應(yīng)集群。

? 可根據(jù)需求??程度確定是由 feature 分?合并，還是直接在上?開發(fā)（?常不建議）。 feature 分?

? feature 分?通常為新功能或新特性開發(fā)分?，以 develop 分?為基礎(chǔ)創(chuàng)建 feature 分 ?。

? 命名以 feature/ 開頭，建議的命名規(guī)則： feature/user_createtime_feature 。

? 新特性或新功能開發(fā)完成后，開發(fā)?員需合到 develop 分?。

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

hotfix分支

? hotfix 分?為線上 bug 修復(fù)分?或叫補(bǔ)丁分?，主要?于對(duì)線上的版本進(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ù)上線，便 將其刪除。

所以遠(yuǎn)端的dev分支并不是我們開發(fā)平臺(tái)的主力，而是本地倉庫的feature分支才是我們開發(fā)人員的主力。

現(xiàn)在引入模型，由于模型十分多，所以這里介紹一個(gè)非常有代表性的模型，也就是Git Flow模型：

對(duì)于這個(gè)模型而言，就是屬于可以持續(xù)交付的模型，也就是隔一段時(shí)間發(fā)布一個(gè)新版本，其實(shí)現(xiàn)在很多軟件都是這個(gè)模型了，畢竟不同的用戶的需求不同，這也就意味著軟件需要不停的更新。

對(duì)于不同的公司的開發(fā)模型是不一樣的，比如騰訊的某個(gè)軟件，阿里的某個(gè)軟件都是，我們現(xiàn)在不妨簡(jiǎn)單模擬一下企業(yè)級(jí)別的開發(fā)流程。

這里放一個(gè)簡(jiǎn)單企業(yè)級(jí)開發(fā)的鏈接，可以容納5個(gè)人，我們畢竟是簡(jiǎn)單學(xué)習(xí)一下，所以要求的平臺(tái)還不用那么高。

Gitee 企業(yè)版 - 企業(yè)級(jí) DevOps 研發(fā)效能平臺(tái)

從這個(gè)界面進(jìn)入，隨便取一個(gè)公司名稱，就可以進(jìn)入了：

項(xiàng)目這里可以簡(jiǎn)單創(chuàng)建一個(gè)項(xiàng)目，對(duì)于剛剛登入這個(gè)號(hào)的人來說，會(huì)有新手導(dǎo)向，也就是自動(dòng)會(huì)出現(xiàn)一個(gè)項(xiàng)目，這是正常的。

新建項(xiàng)目，并且可以關(guān)聯(lián)到自己的倉庫。

創(chuàng)建好了之后就是較為空蕩蕩的。

但是我們還需要?jiǎng)?chuàng)建一下倉庫，在右上角可以新建倉庫，進(jìn)去就是git創(chuàng)建倉庫的部分了?；臼且粯拥?。

需要注意的是這里的分支模型，我們是一個(gè)企業(yè)，所以肯定不能選擇單分支模型的，我們選擇的是生產(chǎn)開發(fā)模型，如果我們選擇的是開發(fā)/發(fā)布/缺陷分離模型，就會(huì)導(dǎo)致后面我們想基于某個(gè)分支創(chuàng)建其他分支是不可以的，因?yàn)檫x擇這個(gè)分支之后，是將我們的分支模型固定了，自由發(fā)揮的空間不是很大。

此時(shí)就創(chuàng)建好了對(duì)應(yīng)的倉庫。

但是一個(gè)企業(yè)不能只有我們一個(gè)人吧，所以我們需要添加成員：

需要你的小伙伴通過鏈接或者是二維碼就可以成功進(jìn)入你的企業(yè)了。

企業(yè)成員有了，還需要項(xiàng)目人員吧？所以需要我們添加項(xiàng)目人員：

項(xiàng)目的添加成員部分就可以添加。

項(xiàng)目人員有了，開發(fā)成員得有吧？所以我們需要添加倉庫開發(fā)人員：

代碼倉庫的這里，就可以添加對(duì)應(yīng)的開發(fā)人員或者是測(cè)試人員等。

那么，簡(jiǎn)簡(jiǎn)單單試試Git Flow？

首先我們要基于Dev分支創(chuàng)建一個(gè)feature分支，畢竟是十分不推薦在Dev分支上進(jìn)行開發(fā)的，所以新建：

新建成功之后，我們現(xiàn)在擁有三個(gè)分支，一個(gè)是feature分支，一個(gè)是dev一個(gè)是master，所以我們現(xiàn)在可以在feature分支上修改一下ReadMe文件，當(dāng)成是代碼開發(fā)：

當(dāng)然了，為了方便，我們這里直接使用本地的IDE作為演示，實(shí)際是不可以在Gitee里面進(jìn)行修改的。

然后左下角有一個(gè)提交，我們點(diǎn)擊提交即可：

上方還需要我們保存一下。

此時(shí)對(duì)于master分支 dev分支是不知道有對(duì)應(yīng)的修改的，所以在feature分支下需要請(qǐng)求代碼評(píng)審，這里就就不能像我們當(dāng)時(shí)學(xué)習(xí)那樣，框的一下就自己提交了。

此時(shí)因?yàn)閒eature分支是基于dev分支創(chuàng)建的，自然是目標(biāo)分支為dev，然后簡(jiǎn)單描述一下Issue即可：

在這里我們直接通過即可。

那么就可以直接進(jìn)行評(píng)審了。

此時(shí)dev分支就合并成功了，本質(zhì)上是開發(fā)人員自測(cè)通過了，所以需要基于dev分支新建一個(gè)Release分支，作為是測(cè)試人員的工作分支：

同樣是在分支管理部分新加。

那么需要pull request，但是合并之后需要?jiǎng)h除分支，因?yàn)檫@個(gè)分支只是作為測(cè)試存在。

此時(shí)master分支就完成了。

對(duì)于實(shí)際中的開發(fā)工作肯定是遠(yuǎn)比本文描述的復(fù)雜的，所以本文只是作為我們?nèi)蘸蟮囊粋€(gè)熱身罷了，各位開發(fā)者加油吧！

感謝閱讀！

柚子快報(bào)激活碼778899分享：初識(shí)git · 有關(guān)模型

http://yzkb.51969.com/

精彩鏈接