分支管理
軟體的版本控制以及分支管理貫穿于整個軟體產品的生命周期，日常的專案管理對于開發團隊能否有節奏且順利的交付軟體也很重要，本分支管理和版本控制規范主要分為3個部分，即分支管理規范、版本號規范、需求與代碼關聯，其中，將闡述不同的分支管理模型，以及它們的優缺點和使用的場景；描述版本號控制方式——語意化版本；以及將需求與代碼管理的必要性等，
分支管理規范
目前比較流行的分支管理模型有三個，即GitFlow、GitLabFlow、GitHubFlow，下面將介紹這三種分支模型的原理，使用場景和優缺點等，
GitFlow
GitFlow是最早誕生并得到廣泛應用的一種作業流程，
該模型中存在兩種長期分支：master和develop，master中存放對外發布的版本，只有穩定的發布版本才會合并到master中，develop用于日常開發，存放最新的開發版本，
也存在三種臨時分支：feature,hotfix,release，
feature分支是為了開發某個特定功能，從develop分支中切出，開發完成后合并到develop分支中，
hotfix分支是修復發布后發現的Bug的分支，從master分支中切出，修補完成后再合并到master和develop分支，
release分支指發布穩定版本前使用的預發布分支，從develop分支中切出，預發布完成后，合并到develop和master分支中，
優點：
feature分支使開發代碼隔離，可以獨立的完成開發、構建、測驗
feature分支開發周期長于release時，可避免未完成的feature進入生產環境
缺點：
無法支持持續發布，
過于復雜的分支管理，加重了開發者的負擔，使開發者不能專注開發，
GitHubFlow
GitHubFlow分支模型只存在一個master主分支，日常開發都合并至master，永遠保持其為最新的代碼且隨時可發布的，
在需要添加或修改代碼時， 基于master創建分支，提交修改，
創建Pull Request，所有人討論和審查你的代碼，
然后部署到生產環境中進行驗證，
待驗證通過后合并到master分支中，
這個分支模型的優勢在于簡潔易理解，將master作為核心的分支，代碼更新持續集成至master上，根據目前收集到的反應來看，得到了更多的好評，認為GitHubFlow分支模型更加輕便快捷，
GitLabFlow
GitLabFlow是GitFlow和GitHubFlow的結合，它吸取了兩者的優點，既有適應不同開發環境的彈性，又有單一主分支的簡單和便利，
該模型采取上游優先的原則，即只存在一個master主分支，它是所以分支的上游，只有上游分支采納的變動才能應用到其他分支，
對于持續發布的專案，建議在master之外再建立對應的環境分支，如預生產環境pre-production，生產環境production，
對于版本發布的專案，建議基于master創建穩定版本對應的分支，如stable-1，stable-2，
分支命名規約
前綴 含義
master 主分支，可用的、穩定的、可直接發布的版本
develop 開發主分支，最新的代碼分支
feature-** 功能開發分支
bugfix-** 未發布bug修復分支
release-** 預發布分支
hotfix-** 已發布bug修復分支
提交命名規約
除了分支的名稱需要規范，提交的命名也同樣如此，
格式為：[操作型別]操作物件名稱，如[ADD]readme，代表增加了readme描述檔案，
常見的操作型別有：
[IML] 實作正在開發的功能
[UPDATE] 更新或改善已經實作的功能
[FIX] 修復BUG
[REF] 重構一個功能，對功能重寫
[ADD] 添加實作新功能
[DEL] 洗掉不需要的檔案
版本號規范
版本格式：主版本號.次版本號.修訂號，版本號遞增規則如下：
1.主版本號：當你做了不兼容的 API 修改，
2.次版本號：當你做了向下兼容的功能性新增，
3.修訂號：當你做了向下兼容的問題修正，
先行版本號及版本編譯資訊可以加到“主版本號.次版本號.修訂號”的后面，作為延伸，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/19592.html
標籤：架構設計
上一篇：StarUML之九、starUML的一些特殊屬性的說明
下一篇：UML之二、建模元素（1）