gitflow工做流

1. 工做流程

項目開始（master、develop）

1. 開發組長，基於master主幹建立develop分支。master和develop就做爲倉庫的兩個主幹，而且將它們的加權限限制，只有管理員可修改。

開發階段（master、develop、feature）

1. 基於develop建立多個feature分支（如：feature/login），對應功能模塊的開發人員，基於該分支開發新功能。
2. 開發人員，測試新功能完成之後，在git上發起pull request把代碼合併到到develop分支上。
3. 開發組長，在確認代碼沒有問題後，經過該pull request 的合併請求。當全部的功能都開發完了，全部的feature分支都合併到develop上。

測試階段-開始測試（master、develop、release）

1. 開發組長，基於develop分支建立一個release預發佈分支（如：release/1.0.0)，並設置release分支只有管理員有權限修改。
2. 基於release/1.0.0分支的代碼進行測試。

測試階段-測試中（master、develop、release、bugfix）

1. 當測試發現bug時，基於當前release/1.0.0分支建立bugfix分支（如：bugfix/問題編號），開發人員基於該bugfix分支進行bug修復。
2. 開發人員在bug修復後，向release/1.0.0分支提交 pull request 申請。
3. 開發組長在確認bug修復完成後，經過該pull request 的合併請求。全部bug修復完成後，當前release版本下，全部bugfix分支都合併到release/1.0.0上。

測試階段-測試完畢（master、develop、tag）

1. 開發組長髮起pull request，把release/1.0.0代碼合併到到master分支上。
2. 基於master分支建立一個里程碑版本(tag)名爲1.0.0-Release，而且在github上發佈一個Release，能夠將當前master代碼以及相關包存檔。
3. 原則上只需保留master、develop兩個分支，和1.0.0-Release里程碑版本（tag）。刪除完成使命的其餘分支：多個feature分支、多個bugfix分支和release/1.0.0。

線上bug-master（master、develop、hotfix）

1. 線上版本出現bug，能夠基於最新版本（master）進行修復，能夠基於master建立hotfix分支（如：hotfix/問題編號），開發人員基於該hotfix分支進行bug修復。
2. 開發人員在bug修復後，向master分支提交 pull request 申請。
3. 開發組長在確認bug修復完成後，經過該pull request 的合併請求。基於master分支建立一個里程碑修復版本(tag)，假如當前版本爲1.2.0-Release，則修復版本爲1.2.1-Release。

線上bug-歷史版本（master、develop、tag、hotfix）

1. 用戶基於某個里程碑版本tag（如：1.0.0-Release）提出bug，建立一個issue。若是master版本已經發布到1.0.0之後了（如：1.2.0-Release），可是該bug修復只能基於歷史的1.0.0修復，就須要基於該里程碑版本(tag)1.0.0-Release，建立一個release/1.0.1分支，和hotfix分支（如：hotfix/問題編號），開發人員基於該分支修復bug。
2. 開發人員在bug修復後，向release/1.0.1分支提交 pull request 申請。
3. 開發組長在確認bug修復完成後，經過該pull request 的合併請求。基於release/1.0.1分支建立一個里程碑修復版本(tag)，名爲1.0.1-Release。

示例代碼（release/*）

# 開始 release

git checkout -b release/0.0.1 develop

# 完成 release

git checkout master

git merge --no-ff release/0.0.1

git push

git checkout develop

git merge --no-ff release/0.0.1

git push

git branch -d release/0.0.1

git push origin --delete release/0.0.1 

# 合併master/devlop分支以後，打上tag 

git tag -a v0.1.0 master

git push --tags

2. 分支說明

master

• master 分支爲主分支，用於部署生產環境，須要確保master分支的穩定性。
• 此分支屬於只讀分支，只能從 release或hotfix 分支合併過來，任什麼時候候都不能在此分支修改代碼。
• 全部向master分支的推送，都要打上tag標籤記錄，方便追溯。
• 此分支只能前進，不能有回退操做。

develop

• develop 爲開發環境主幹分支，基於 master 分支檢出。
• 此分支爲只讀分支，只能從master、release、feature分支合併過來，任什麼時候候都不能在此分支修改代碼。
• 此分支只能由開發人員提交 pull request（須要 code review），或者由管理員 merge release 分支。
• 在一個 release 分支沒有建立出來時，develop 分支不能合併不包含 release 功能範圍的 feature 分支。develop 分支在特殊狀況下能夠回退版本。

release/*

• release 分支爲預上線分支，基於 develop 或 master 分支檢出。用於準備發佈新階段版本或者修復線上bug版本。
• 此分支用於上線前bug測試，文檔生成和其餘面向發佈任務。
• 此分支屬於只讀分支，只能由 master 分支或者 develop 分支檢出，或者從 bugfix 分支、hotfix 分支合併過來，任什麼時候候都不能在此分支修改代碼。
• 此分支屬於臨時分支，在發佈提測階段，會以 release 分支代碼爲基準提測。當 release 分支測試驗證經過後，最終會先被合併到 master 分支（發佈新版本或者修復線上bug，要打tag標籤），再被合併到 develop 分支（使其與 master 分支保持一致），最後刪除此分支。
• 命名：release/<版本號>（例：release/1.0.0）

feature/*

• feature 分支爲功能開發分支，由開發人員基於 develop 分支建立 feature/<功能模塊> 分支。
• 此分支用於新功能開發，一個 feature 分支最大粒度只能到模塊。
• 此分支爲臨時分支，最終會被合併到 develop 分支（新增功能），或者刪除（放棄功能）。
• 此分支一般僅存在於開發人員本地存儲庫中，而不存在與遠程origin。
• 一個新功能開發完成後，且在開發集成環境自測經過、單元測試經過、Sona掃描經過後，才能向 develop 分支提交 pull request （須要 code review）。

bugfix/*

• 預上線 bug 修復分支，基於 release 分支檢出。
• 此分支用於上線前bug修復。
• 此分支屬於臨時分支，當提測階段中存在 bug 須要修復，由開發人員基於 release 分支建立 bugfix/<bug名字> 分支，而後在 bugfix/<bug名字> 分支進行修復 bug 。 bug 修復完成後，而且在開發集成環境自測經過、單元測試經過、Sona掃描經過後，再向 release 分支提交 pull request 申請。bug修復完成 release 分支測試經過以後可刪除此分支。

hotfix/*

• 生產環境 bug 修復分支，基於 master 分支檢出。
• 屬於臨時分支，當生產環境出現 bug ，管理員基於 tag 建立 hotfix/<bug名字> 分支、 release/<版本號> 分支，由開發人員在hotfix分支修復bug，修復完成後，而且在開發集成環境自測經過、單元測試經過、Sona掃描經過後，再向 release 分支提交 pull request 申請。bug修復完成上線以後可刪除此分支。

總結

• 只有 master 和 develop 兩個分支是主幹分支，一直存在的。其餘分支都是功能性分支，在完成歷史使命後會，能夠被刪除。
• master、develop 和 release/* 三種分支是被鎖住的只讀分支，只有管理員有權限修改。只能合併，不能直接提交，其餘人想要合併只能提交 pull request。

3. 版本號

在前文不少地方都涉及到版本號，例如：release/* 分支、提交tags和發佈Release版本等，版本號的命名也須要有必定的規範。

版本號（公開）

對外正式發佈的版本號，通常只須要經過三位數字的版本號：主版本號.次版本號.修訂號：

• 主版本號：作了一些不兼容的API修改，能夠理解爲一個大的產品更新。
• 次版本號：新增了一些功能，能夠理解爲合併了一個feature。
• 修訂號：修復了一些bug，能夠理解爲合併了一個hotfix。

版本號（測試）

假如咱們想要發佈 1.0.1 版本，在開發團隊內部，可能會提交屢次的測試版本，交付給測試人員測試。這時候須要基於 1.0.1 版本號後面，加上一些其餘的版本號。

• alpha：內測版，通常不向外部發布，bug會比較多，功能也不全，通常只有測試人員使用。
• beta：公測版，該版本仍然存在不少bug，但比alpha版本穩定一些。這個階段版本還會不斷增長新功能。
• RC：發行候選版本，基本再也不加入新的功能，主要修復bug。是最終發佈成正式版的前一個版本，將bug修改完就能夠發佈成正式版了。
• Release：正式發佈版，官方推薦使用的版本。在正式發佈的時候，能夠不加Release，即 1.0.1 等同於 1.0.1-Release

可能基於這些版本號還有更細緻的劃分，這個能夠根據實際項目狀況調整。例如：v1.0.0-beta.一、v1.0.0-beta.2，或v1.0.0-200910-beta等。