Git開發分支使用與管理規范

最穩定的代碼放在 master 分支上(相當于 SVN 的 trunk 分支),我們不要直接在 master 分支上提交代碼,只能在該分支上進行代碼合并操作,例如將其它分支的代碼合并到 master 分支上。
我們日常開發中的代碼需要從 master 分支拉一條 develop 分支出來,該分支所有人都能訪問,但一般情況下,我們也不會直接在該分支上提交代碼,代碼同樣是從其它分支合并到 develop 分支上去。
當我們需要開發某個特性時,需要從 develop 分支拉出一條 feature 分支,例如 feature-1 與 feature-2,在這些分支上并行地開發具體特性。
當特性開發完畢后,我們決定需要發布某個版本了,此時需要從 develop 分支上拉出一條 release 分支,例如 release-1.0.0,并將需要發布的特性從相關 feature 分支一同合并到 release 分支上,隨后將針對 release 分支部署測試環境,測試工程師在該分支上做功能測試,開發工程師在該分支上修改 bug。待測試工程師無法找到任何 bug 時,我們可將該 release 分支部署到預發環境,再次驗證以后,均無任何 bug,此時可將 release 分支部署到生產環境。待上線完成后(注:一般master對應著發布版本,應從master發布),將 release 分支上的代碼同時合并到 develop 分支與 master 分支,并在 master 分支上打一個 tag,例如 v1.0.0。
當生產環境發現 bug 時,我們需要從對應的 tag 上(例如 v1.0.0)拉出一條 hotfix 分支(例如 hotfix-1.0.1),并在該分支上做 bug 修復。待 bug 完全修復后,需將 hotfix 分支上的代碼同時合并到 develop 分支與 master 分支。
對于版本號我們也有要求,格式為:x.y.z,其中,x 用于有重大重構時才會升級,y 用于有新的特性發布時才會升級,z 用于修改了某個 bug 后才會升級。針對每個微服務,我們都需要嚴格按照以上開發模式來執行。
針對每個服務的開發工作,我們都需要嚴格按照以上開發規范來執行。
實際上,我們使用的開發規范是業界知名的 Git Flow,可通過以下博客地址了解 Git Flow 的詳細過程:
http://nvie.com/posts/a-successful-git-branching-model/。
摘自:https://blog.csdn.net/penker_zhao/article/details/51132514

浙公網安備 33010602011771號