Git Flow工做流程

1、編寫的目的

• 經過規範化的流程，使得產品、開發與測試等各個部門更高效的協同工做。
• 經過規範化的流程使得產品高效穩定運行。

2、背景

在多組員、多項目、多環境進行協同工做時，若是沒有統一規範、統一流程，則會致使額外的工做量、出現版本混亂或代碼覆蓋。因此要減小版本衝突，減輕沒必要要的工做，就須要規範化的工做流程。

3、總則

• 統一使用Git做爲版本控制的主要工具。
• 統一使用GitFlow流程管理控制版本。

4、提交的準則

• 除了源碼相關的東西以外，其餘build產生的東西（如：maven的target文件夾，.idea文件夾等），均不能提交進入源碼倉庫，添加到.gitignore文件中忽略掉。
• 撰寫規範的commit說明,一份好的提交說明能夠幫助協做者更輕鬆更有效地配合工做。
• 要嚴格按照咱們指定的流程切換到指定分支，開發相應的功能。

5、Git Flow的流程圖

6、分支簡述

• 天藍色圓點所在的線爲咱們源碼的主線（master）。
• 天藍色方形指向的節點就是每個發佈版本的標籤（tag）。
• 紫色圓點所在的線爲主要分支線（develop）。
• 橙色圓點所在的線爲新功能開發分支線（feature）。
• 綠色圓點所在的線爲新版本發佈線（release）。
• 紅色圓點所在的線爲發佈版本bug修復線（hotfix）。

6.1 主分支

1. master:用來記錄官方發佈軌跡。
2. develop:是一個集成分支，用來記錄完整的開發過程軌跡。

6.2 臨時的分支

1. 新功能分支（Feature Branches）

   每個新的功能或者下一個迭代的任務,都應該建立一個獨立的功能分支，從develop分支中派生出來。當功能完成後，要合併（merged）回develop分支，合併後它的生命週期就結束,能夠刪除。新功能分支不會與master分支有直接的交匯。如圖：

2. 發佈分支（Release Branches）

   一旦開發的功能已經知足發佈條件（或預約發佈日期接近），應該合併全部知足發佈條件的新功能分支到develop分支中，而後，開出一個發佈分支（Release），開始準備一個發佈版本。Release這個分支上不能再添加新的功能，只有bug修復和該版本爲導向的任務。一旦到了發佈日期，Release就要合併回master發佈，而且打出版本標籤。另外還須要合併回develop分支,保證develop分支是最新的.

   使用一個專門的分支來準備發佈版本，使得一個團隊能對當前版本進行拋光，而另外一個團隊繼續爲下一個版本的功能作準備。它還創造了良好定義的發展階段（例如，很容易說，「本週咱們正在準備4.0版」，並且真實地看到它在庫中的結構）

3. 維護分支（Maintenance Branches）

   維護分支也就是線上bug修復分支，使用來快速修復生產環境的緊急問題

   這個分支是惟一一個開放過程當中直接從master分支派生來的分支。快速的修復問題後，它應該被合併回master和develop（或者當前發佈分支），而後，master分支須要打一個版本標籤。

6.3 命名約定

• 主分支名稱：master
• 主開發分支名稱：develop
• 標籤（tag）名稱：v*.RELEASE，其中」*「 爲版本號，「RELEASE」大寫，如：v1.0.0.RELEASE
• 新功能開發分支名稱：feature-，其中」「 爲新功能簡述，如：feature-item-activity-list
• 發佈分支名稱：release-，其中」「爲版本號，「release」小寫，如：release-1.0.0
• master的bug修復分支名稱：hotfix-，其中」「爲bug簡述，如：hotfix-item-update-bug

七.工做流程

下面具體演示如何使用工做流來管理版本發佈週期。假設咱們已經存在或建立了一個源碼中央存儲倉庫,默認建立了master分支。

7.1 建立develop分支

• 項目負責人在本地master基礎上建立一個develop分支，而後，推送到服務器；

git branch develop
git push -u origin develop

• 其餘開發人員，須要克隆develop中央倉庫的源碼，建立一個develop的軌跡版本；若是已經克隆過該項目，則不須要執行如下第一條命令。

git clone git@github.org:search-cloud/demo.git
git checkout -b develop origin/develop

develop這個分支將包含項目的完整歷史記錄，而master將包含縮略版本。

7.2 新建feature分支

• 基於develop分支建立新功能分支(多個團隊能夠拉取多個功能分支,互不影響)：

git checkout -b feature/demo develop

• 推送到遠程倉庫:

git push

• 全部開發此新功能的人員，都在此分支上開發提交代碼:

git status
git add
git commit -m "Add some-file."

7.3 完成新功能開發（合併feature分支到develop）

當肯定新功能開發完成，且聯調測試經過，而且新功能負責人已經獲得合併feature分支到develop分支的容許；這樣才能合併feature分支到develop. (若是有兩個新功能同時在開發,前一個功能合併到develop,但尚未發佈到release,而且下一個版本又不在這個週期發佈.則第二個功能不能合併到develop,不然會出現兩個新功能同時要發佈到release)

git pull origin develop
git checkout develop
git merge feature/demo
git push
git branch -d feature/demo

第一條命令是確保在合併新功能以前，develop分支是最新的

注意:

• 新功能分支，永遠不要直接合併到master分支。
• 合併可能會有衝突，應該謹慎處理衝突

7.4 在測試環境發佈develop分支代碼（提交測試）,也能夠跳7.5建立release分支提測

7.5 線上版本發佈流程

• 從develop中建立準備發佈的release分支

• 當主測試流程完成，源碼已經趨近於穩定狀態，應該準備一個發佈版本，確立版本號,並把master代碼合併到release發佈版,確保release是要發佈的最新的代碼

git checkout -b release-0.1.0 develop
git merge master
git push

這個分支是清理準備發佈、 總體迴歸測試、 更新文檔，不能在此分支添加與本次無關的新功能

• 繼續拋光改bug
• release分支合併到master發佈

一旦已經知足發佈條件（或已經到了預約發佈日期），應該把release分支合併到master分支和develop分支中，而後，使用master發佈新版本。合併release分支到develop分支是很重要的，要讓release上修改的東西能在後續的開發分支中生效。

git checkout master
git merge release-0.1.0
git push

• release分支合併到develop

git checkout develop
git merge release-0.1.0
git push
git branch -d release-0.1.0

• master打標籤,用此標籤代碼作最後上線驗證

Release分支在功能開發分支（develop）和公共發佈版（master）中，充當一個緩衝的做用。每當有源碼合併到master中的時候，應該在master上打一個標籤，以便後續跟蹤查閱。

git tag -a 0.1.0.RELEASE -m "Initial public release" master
git push --tags

7.6 線上Bug修復流程 當終端用戶，反饋系統有bug時，爲了處理bug，須要從master中建立出保營養支；等到bug修復完成，須要合併回master/develop：

• 建立hotfix分支

git checkout -b issue-#001 master

• 修改bug Fix the bug
• 完成修復，合併到master發佈

git checkout master
git merge issue-#001
git push

• 打標籤

git tag -a 0.1.1.RELEASE -m "Initial public release" master
git push --tags

• 合併到develop

git checkout develop
git merge issue-#001
git push