你們都比較清楚,互聯網產品要可以快速響應市場變化,要面對頻繁的需求變動,要用廉價的成本快速試錯,這樣才能不斷的完善和優化產品。 git
Git是一個開源的分佈式版本控制系統,能夠有效、高速的處理從很小到很是大的項目版本管理。很是適合作互聯網產品的代碼版本管理。分佈式
一個團隊如何如何使用git進行版本管理,如何使用git進行多人的代碼寫做?如何解決產品開發過程當中的提出來的版本控制的問題?就是我要表達的意思。測試
團隊如何進行版本管理呢?優化
我選用了GitLab做爲GitServer。GitLab是一個開源的版本管理系統,實現一個自託管的Git項目倉庫,可經過Web界面進行訪問公開的或者私人項目。它擁有與Github相似的功能,可以瀏覽源代碼,管理缺陷和註釋等,還有一個功能,它可以實現分支的在線合併申請,分支能夠進行保護等權限的控制。編碼
約定版本號規範,每一個模塊的版本號約定爲三位<main>.<feature>.<hotfix>,根據大的基線設定<main>主要版本號,根據當前版本設定<feature>次版本號,<hotfix>默認爲0,當有bug修改後才更新這個版本號。每次產品人員定義好產品功能後,每次變動<feature>版本號便可。版本控制
每建立一個項目,分別建立dev、test、release、master四個固定分支。繼承
dev分支用來研發人員進行自測和模塊間聯調使用的,用來部署到研發環境的,開發人員對該分支有pull和push權限。開發
test分支是測試人員進行測試的代碼分支,是部署到測試環境的代碼分支,研發人員聯調完自測完成後,提交feature分支合併申請到test分支,由管理員負責代碼review並進行代碼合併,該分支是受保護分支,開發人員對該分支有pull權限。部署
release分支是在test分支測試完成後,由研發人員提交test分支合併申請到release分支,release代碼分支是用來部署到預生產環境的,由管理員進行代碼合併。get
master分支是最終上線的代碼分支,測試人員在預生產環境測試經過後,由研發人員提交release代碼分支合併申請到master分支,master分支是要部署到生產環境的,master上線完成後打對應版本的tag標籤。
feature分支,每次定義產品一個完整的基線版本就生成一個feature_{版本號}分支,上線完成後刪除該分支,全部的人建立一個屬於本身的分支,每一個人自測完成後,發起本身分支合併到feature分支,而後將feature分支合併到dev分支。
hotfix分支,每次bug修復建立一個hotfix_{版本號}分支,生產環境出現bug後,須要立刻修改時,肯定好版本號,從繼承master分支建立hotfix分支。
1)管理員建立固定的分支dev、test、release和master版本,根據產品人員肯定的功能肯定當前版本的版本號,並繼承master分支建立feature分支。
2)每一個研發人員拉取feature分支,並建立我的本地分支。
3)研發人員進行編碼,自測完成後合併本地分支合併到feature分支,並將feature分支合併到dev分支部署到研發環境進行模塊間聯調。
4)研發人員聯調經過之後,向管理員發起feature分支合併到test分支的申請,由管理員review代碼後完成合並,並部署到測試環境。
5)測試人員在測試環境進行測試,發現bug並登記,由研發人員進行修改,從新從第3步開始重複執行。
6)測試人員測試經過之後,由研發人員發起從test分支向release分支合併申請,由管理員完成合並,並部署到預生產環境。
7)測試人員測試預生產環境測試經過後,由研發人員發起從release分支向master分支的合併申請,有管理員完成合並,並在master分支上打版本標籤,並部署到生產環境。
8)測試人員驗證生產環境經過後,上線完成,若是生產環境驗證不經過,立刻回滾到master上一次的版本代碼。
1)研發人員從繼承master分支建立一個hotfix分支。
2)研發人員檢出hotfix分支,自測經過後提交併申請分支合併到release分支,由管理審覈經過後完成合並,並部署到預生產環境。
3)由測試人員對預生產環境進行測試,測試經過後,由研發人員發起從release分支合併到master分支的申請,由管理員審覈經過後完成合並,並在master分支上打版本標籤,並部署到生產環境。
4)測試人員驗證生產環境經過後,上線完成,若是生產環境驗證不經過,立刻回滾到master上一次的版本代碼。
以上就是我使用GitLab進行版本管理的實際使用過程,你們有什麼想法能夠關注個人公衆號(xtech100)一塊兒討論。
我在百家號上文章地址