引言

編寫的目的

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

背景

在多組員，多專案等環境進行協同工作時，如果沒有統一規範、統一流程，則會導致額外的工作量，甚至會做無用功。所以要減少版本衝突，減輕不必要的工作，就需要規範化的工作流程。

總則

-統一使用Git作為版本控制的主要工具。
-統一使用GitFlow流程管理控制版本。

提交的準則

1.除了原始碼相關的東西之外，其他build產生的東西（如：maven的target資料夾，.idea資料夾等），均不能提交進入原始碼倉庫，新增到.gitignore檔案中忽略掉。

分支簡述

我們使用的分支流程：

主要分支簡述

-天藍色圓點所在的線為我們原始碼的主線（master）。

-天藍色方形指向的節點就是每一個釋出版本的標籤（tag）。
-紫色圓點所在的線為主要分支線（develop）。
-橙色圓點所在的線為新功能開發分支線（feature）。
-綠色圓點所在的線為新版本釋出線（release）。
-紅色圓點所在的線為釋出版本bug修復線（hotfix）。

主分支說明

代替原來的單個主線（master），我們使用兩個分支來記錄原始碼軌跡：
1.原來的master分支用來記錄官方釋出軌跡；
2.新的develop分支是一個整合分支，用來記錄開發新功能的軌跡。

Master與Develop分支

除了master主線和develop主分支線，其他的分支都是臨時的分支，有一定的生命週期的，其餘的工作流程分支都是圍繞這兩個分支之間的區別進行的。

其他分支說明

-新功能分支（Feature Branches）

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

Feature Branches

注意：對於所有意圖和目的，新功能分支會合併到develop分支。但是，這個Gitflow工作流不會在此結束。

-釋出分支（Release Branches）

一旦開發的功能已經滿足釋出條件（或預定釋出日期接近），應該合併所有滿足釋出條件的新功能分支到develop分支中，然後，開出一個釋出分支（Release），開始準備一個釋出版本。在這個分支上，不能再新增新的功能，只有bug修復和該版本為導向的任務。一旦到了釋出日期，Release就要合併回master釋出，並且，打出版本標籤。另外，還需要合併回develop分支。

Release Branches

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

-維護分支（Maintenance Branches）

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

Maintenance Branches

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

一個專門的錯誤修復開發線，可以讓團隊在不等待下一個釋出週期，導致中斷工作流程情況下解決問題。可以將維護分支當做主要的問題修復分支，與master並行。

命名約定

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

工作流程

下面具體演示如何使用工作流來管理版本釋出週期。假設我們已經存在或建立了一個原始碼中央儲存倉庫。

工作流的基礎

建立develop分支

Create Develop Branch

-專案負責人在本地master基礎上建立一個develop分支，然後，推送到伺服器；

git branch develop
git push -u origin develop

-其他開發人員，需要克隆develop中央倉庫的原始碼，建立一個develop的軌跡版本；如果，已經克隆過該專案，則，不需要執行以下第一條命令。

git clone [email protected]:search-cloud/demo.git
git checkout -b develop origin/develop

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

** 假設開始以下所有的流程之前，都已經建立好develop分支。**

新功能開發流程

1.新建feature分支

Create Feature Branch

基於develop分支建立新功能分支：

git checkout -b feature/demo develop

推送到遠端倉庫，共享：

git push

所有開發此新功能的人員，都在此分支上開發提交程式碼。

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

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

Merge Feature to Develop

當確定新功能開發完成，且聯調測試通過，並且新功能負責人已經得到合併feature分支到develop分支的允許；這樣才能合併feature分支到develop。

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

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

注意：

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

3.在測試環境釋出develop分支程式碼（提交測試）

線上版本釋出流程

1.從develop中建立準備釋出的release分支

Create Release Branch

當主測試流程完成，原始碼已經趨近於穩定狀態，應該準備一個釋出版本，確立版本號：

git checkout -b release-0.1.0 develop

推送到遠端倉庫共享：

git push

這個分支是清理準備釋出、 整體迴歸測試、 更新文件，和做其他任何系統即將釋出的事情。

2.繼續拋光改bug
3.release分支合併到master釋出

Merge Release to Master and Develop

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

git checkout master
git merge release-0.1.0
git push

4.release分支合併到develop

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

5.打標籤

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

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

線上Bug修復流程

當終端使用者，反饋系統有bug時，為了處理bug，需要從master中創建出保養分支；等到bug修復完成，需要合併回master：

1.建立hotfix分支

git checkout -b issue-#001 master

2.修改bug Fix the bug
3.完成修復，合併到master釋出

Merge hotfix to Master

git checkout master
git merge issue-#001
git push

4.打標籤

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

5.合併到develop

git checkout develop
git merge issue-#001
git push

其他

附錄

參考資料

作者：一憶
連結：https://www.jianshu.com/p/9a76e9aa9534
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。