分支管理 軟體的版本控制以及分支管理貫穿於整個軟體產品的生命周期，日常的項目管理對於開發團隊能否有節奏且順利的交付軟體也很重要。本分支管理和版本控制規範主要分為3個部分，即分支管理規範、版本號規範、需求與代碼關聯。其中，將闡述不同的分支管理模型，以及它們的優缺點和使用的場景；描述版本號控制方式——語 ...
分支管理
軟體的版本控制以及分支管理貫穿於整個軟體產品的生命周期，日常的項目管理對於開發團隊能否有節奏且順利的交付軟體也很重要。本分支管理和版本控制規範主要分為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.修訂號：當你做了向下相容的問題修正。
先行版本號及版本編譯信息可以加到“主版本號.次版本號.修訂號”的後面，作為延伸。
