【技術博客】Git Flow模型管理代碼版本

參考GIT版本管理：Git Flow模型，在此基礎上加入了本身的理解，增長人員分工和相應代碼，並根據本次項目的實際狀況進行相應修改。

在本學期的軟件工程開發過程當中，咱們從alpha階段就使用了git flow模型進行git代碼版本管理。鑑於咱們的開發團隊存在開發人數較少（7人）、任務週期固定（一次任務持續半周/一週）、成員各自任務之間關聯性小、無需在版本發佈前完成全面測試的特色，將傳統的git flow模型進行了簡化和實踐。

本篇博客講解咱們使用的簡化git flow模型，並提供了咱們用到的全部指令代碼，但願能給你們的開發帶來幫助。本文再也不去講解最基礎的代碼提交、分支切換原理和流程。有任何錯誤或者疑問，能夠在評論區指出和討論～

完整git flow模型如圖：

人員職責

開發者：全部人員都爲開發者，能夠對代碼進行修改和提交。但開發者只容許從develop分支拉取我的feature分支後修改，commit後merge到develop中，而不容許直接改動develop分支，更不容許對master分支有任何操做。

版本管理者：本團隊有1名版本管理者，負責在一次任務週期的最後階段，全部人的提交所有merge到develop後，對master分支的相關操做，以更新master分支。

分支概述

遠程分支

master：只有版本管理者有權利進行操做。簡單地說，master上的每一個版本都應該是相對穩定的版本，是每一次全部開發者的開發任務結束後留檔的版本。

develop：每一個開發者均可以從develop分支上拉取新分支，開發完成後合併到develop分支。

本地分支

master：鏈接遠程master分支。

develop：鏈接遠程develop分支。

feature：在一個任務週期中，從develop拉取，進行修改和提交。完成該週期的我的任務後，合併到develop分支，並將本地的feature分支刪除。feature分支不容許提交到遠程，即不容許在feature分支中出現push操做。feature分支以開發者名字簡寫命名。

release：在一個任務週期的最後階段，全部人的提交所有merge到develop後，從develop分支拉取release分支，進行必定的測試。測試結束後合併到master和develop分支，並刪除本地release分支。release分支以'release-x.x'命名，如‘release-0.9’，‘release-0.10’，‘release-1.0’等。release分支不容許提交到遠程

一些約定

在每次add指令前，經過git branch查看分支是否正確。在每次git add .前，經過git status查看修改的文件。

具體操做

開發者

在一週的開發任務分配後，從develop建立本身的feature分支，以姓名簡寫命名：

任意分支下git checkout -b yourname develop

完成一部分開發任務後，提交代碼：

git add filename
git commit -m "what have you changed"

注意並不push，即該分支只出如今本地。

重複上條，直到本次我的任務完成。提交到develop中：

git checkout develop
git pull origin develop       # 拉取遠程develop代碼到最新版本，防止merge出現衝突
git merge --no-ff yourname    # --no-ff不使用fast-forward方式合併，保留分支的commit歷史
git push origin develop

刪除本地feature分支：

git branch -d yourname

分支管理者

在該任務週期結束，全部人都merge到develop分支後，建立release分支，以'release-x.x'命名：

任意分支下git checkout -b release-0.1 develop

進行簡單測試後，若是出現bug，在release分支下修改，提交：

git add filename
git commit -m "what have you changed"

將release分支合併到master分支：

git checkout master
git merge --no-ff release-0.1
git tag 0.1            # 對正式版本打tag

若是在release上修改過代碼，還要合併到develop分支：

git checkout develop
git merge --no-ff release-0.1

將tag推送到遠程，並將master更新：

git push --tags
git push

刪除本地release分支：

git branch -d release-0.1

對git flow的簡化和實踐中的問題

採用git flow後的git network如圖：

• 簡化hotfix分支：hotfix分支用於在master出現bug後緊急修復。由於咱們項目的迭代較快，用戶較少，衡量新建hotfix分支的複雜程度，暫時刪去。但在更大規模的項目中，hotfix很值得使用。

• git flow的優勢：遠程只有master和develop兩個分支，且除版本管理者外他人無權修改master代碼，保證出現問題時，進行修復工做的目的清晰。

• 對測試人員的不友好：理論上，release分支的做用包括了對即將發佈版本的測試。可是能夠發現，此處的release分支僅僅爲本地分支，即版本管理者在將develop分支發佈到master分支的過程當中，測試人員是沒法切換到release分支的。這一點對測試人員並不友好。但在咱們的項目中，反而比較合適。因爲項目屬於課程設計，且不具備盈利性，要求測試人員在版本上線當晚必須投入到測試工做並不合理。經過衡量等待測試完成的時長和上線後出現bug的嚴重性，咱們決定採用目前的分支管理方法，即在分支管理人員在release分支運行自動化測試工具進行功能測試後，發佈到master分支。測試人員在以後的幾天裏，對項目新增代碼進行代碼級別的測試。

• 對開發結束後再次修改代碼的不友好：能夠發現，在結束本身本週期的開發任務，刪除本地feature分支後，若是再次發現本身的修改存在bug，仍然須要從新拉取feature分支，這是一個比較繁瑣的過程。咱們也發現了存在部分紅員在此時會直接進入develop分支修改代碼。

• git branch和git status相當重要：提交錯了分支和文件引起的版本回滾比較繁瑣，所以提交前必定注意，要對本身的提交動做負責。