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