分支管理
軟件的版本控制以及分支管理貫穿於整個軟件產品的生命周期，日常的項目管理對於開發團隊能否有節奏且順利的交付軟件也很重要。本分支管理和版本控制規范主要分為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.修訂號：當你做了向下兼容的問題修正。
先行版本號及版本編譯信息可以加到“主版本號.次版本號.修訂號”的后面，作為延伸。