我與Git的那些破事--代碼管理

時間 2020-01-09

標籤 git 那些代碼管理欄目 Git 简体版

原文原文鏈接

1. Git是什麼？

做爲一名程序猿，我相信你們都或多或少接觸過git--分佈式版本控制軟件。git

有人說，它是目前世界上最早進的分佈式版本控制系統，我想說，是否最早進不知道，但確實好用，實用。分佈式

做爲一款風靡全球的軟件，不得不提提它的歷史：工具

--由Linus Torvalds創做，並與2005首次發佈，最初僅是爲更好的管理Linux核心開發而設計，未曾想太優秀，現在已被廣爲使用。測試

做爲一款分佈式版本控制軟件，聽上去高端大氣上檔次，但說白了，就是一款項目代碼管理工具。設計

既然Git如此好用，理所固然，目前全球各大公司大多采用該軟件做爲項目代碼的管理工具。版本控制

猶記得當初剛從學校進入企業，發現原來公司的代碼是這樣管理的，看上去猴塞雷的樣子。固然，伴隨着操做當心翼翼，生怕一頓操做猛如虎，犯錯回家賣紅薯。。blog

做爲一個接觸多年的老手，則肆無忌憚，斧削刀砍，好不快活。講真，那會羨慕的不要不要～～生命週期

其實，只要懂得正確操做流程，你也能夠大刀闊斧，那麼下面的知識，你值得擁有！！項目管理

好了，閒話就此打住，仍是得來點乾貨。資源

我相信你們必定聽過一句話：做爲一款穩定的產品，咱們必定要保證項目運行的四個九。咋聽之下，一臉狐疑。其實，意爲保證項目運行99.99%（至於那遁去的1，你懂的），即高可用的又一說法。

爲保證項目高可用，產品上線必須嚴格遵照必定的流程。

這裏提幾個概念，可能與你所在公司說法不太同樣，但我相信都是換湯不換藥，領略精髓便可，大可沒必要咬文嚼字。

Git 分支：

部署環境：

DEV/Local環境--本地環境。通常而言，程序猿接到一個新的需求時，會在本地開發，完成後本身測試，這裏稱爲本地環境（固然財大氣粗的公司可能會專門準備一套DEV環境用於測試）。
QA環境--與產線環境配置一致（單實例）。需求本地測試經過後，部署到QA環境中，由QA進行測試。因爲QA環境部署頻繁，若是多實例部署會形成資源和時間上的浪費。
BTS環境--與產線環境徹底一致（分佈式）。在版本發佈前，部署到BTS環境，該環境和產線環境徹底一致。通常會在版本發佈前3天部署到該環境，作UAT（用戶接受測試）。
PROD環境--分佈式系統。產線環境。

開發流程：

當團隊接到新的需求時，通常會安排某個或某幾個程序猿來開發該功能。在瞭解完需求和設計後，開發會拉出對應的feature分支，全部該需求的代碼都將在該分支上進行開發。
當開發完成，爲驗證功能可行性，程序猿須要在本地進行對應測試，經過後將代碼合入到dev分支。
利用Jenkins從dev分支中進行打包，而後部署到QA環境中，由團隊中專職QA進行功能測試。測試不經過，上述步驟重複。測試經過，該需求結束。

這裏，有些小夥伴則會問，爲何本地測試經過了，而在QA環境中卻不經過呢？

一般，一個團隊都會同時接多個需求，你們的代碼都會並行往dev中合入，這時就有可能影響到其餘的需求，或者被其餘需求影響，致使bug。

Git詳細流程：

開發流程：

當發佈新版本時，以時間或需求結束點爲節點，打對應tag（方便之後回溯）。從該tag拉出release分支，Jenkins從release分支打包。
將包部署到QA環境，由專職QA進行測試。
- 若是測試不經過，從release分支中拉出hotfix分支，在hotfix分支上進行bug修復，本地測試完畢，Jenkins從hotfix分支打包，部署到QA環境測試。
- 測試經過，下一步。
將包部署到BTS環境，由專職QA進行測試。測試不經過，判斷當前分支，若爲release分支，則從該分支拉出hotfix分支，在hotfix修復bug後；若爲hotfix分支，則直接修改bug，本地測試完畢，Jenkins打包hotfix分支，部署到QA測試。
將包部署到PROD環境，由專職QA進行測試，測試不經過，判斷當前分支，若爲release分支，則從該分支拉出hotfix分支，在hotfix修復bug後；若爲hotfix分支，則直接修改bug，本地測試完畢，Jenkins打包hotfix分支，部署到QA測試。

Git詳細流程：

上述的內容，僅爲我的多年開發經驗總結，或許與標準流程有必定的出入。

若有錯誤之處，忘各位大佬不吝斧正。

做者：吳家二少

本文歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接