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

http://yzkb.51969.com/

目錄

前言：

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

前言：

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

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

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

其實追其本源，都是從程序員的負責模塊引出來的。

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

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

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

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

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

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

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

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

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

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

那么對于分支來說：

master 分?

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

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

? master 分?不可刪除。

release 分?

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

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

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

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

develop 分?

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

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

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

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

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

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

hotfix分支

? hotfix 分?為線上 bug 修復分?或叫補丁分?，主要?于對線上的版本進? bug 修復。當線上 出現(xiàn)緊急問題需要?上修復時，需要基于 master 分?創(chuàng)建 hotfix 分?。

? 命名以 hotfix/ 開頭，建議的命名規(guī)則: hotfix/user_createtime_hotfix ? 當問題修復完成后，需要合并到 master 分?和 develop 分?并推送遠程。?旦修復上線，便 將其刪除。

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

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

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

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

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

Gitee 企業(yè)版 - 企業(yè)級 DevOps 研發(fā)效能平臺

從這個界面進入，隨便取一個公司名稱，就可以進入了：

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

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

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

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

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

此時就創(chuàng)建好了對應的倉庫。

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

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

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

項目的添加成員部分就可以添加。

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

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

那么，簡簡單單試試Git Flow？

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

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

當然了，為了方便，我們這里直接使用本地的IDE作為演示，實際是不可以在Gitee里面進行修改的。

然后左下角有一個提交，我們點擊提交即可：

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

此時對于master分支 dev分支是不知道有對應的修改的，所以在feature分支下需要請求代碼評審，這里就就不能像我們當時學習那樣，框的一下就自己提交了。

此時因為feature分支是基于dev分支創(chuàng)建的，自然是目標分支為dev，然后簡單描述一下Issue即可：

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

那么就可以直接進行評審了。

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

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

那么需要pull request，但是合并之后需要刪除分支，因為這個分支只是作為測試存在。

此時master分支就完成了。

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

感謝閱讀！

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

http://yzkb.51969.com/

精彩鏈接