Git分支管理介紹

分支管理

軟件的版本控制以及分支管理貫穿於整個軟件產品的生命週期，平常的項目管理對於開發團隊可否有節奏且順利的交付軟件也很重要。本分支管理和版本控制規範主要分爲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.修訂號：當你作了向下兼容的問題修正。

先行版本號及版本編譯信息能夠加到「主版本號.次版本號.修訂號」的後面，做爲延伸。