Git Flow工作流程
1.使用背景
在多組員，多項目等環境進行協同工作時，如果沒有統一規范、統一流程，則會導致額外的工作量，甚至會做無用功。所以要減少版本沖突，減輕不必要的工作，就需要規范化的工作流程。
2.使用總則
- 統一使用Git作為版本管理工具。
- 統一GitFlow流程管理控制版本。
3.分支
git-flow的分支流程圖
- 天藍色圓點所在的線為我們源碼的主線（master）。
- 天藍色方形指向的節點就是每一個發布版本的標簽（tag）。
- 紫色圓點所在的線為主要分支線（develop）。
- 橙色圓點所在的線為新功能開發分支線（feature）。
- 綠色圓點所在的線為新版本發布線（release）。
- 紅色圓點所在的線為發布版本bug修復線（hotfix）。
長期分支 & 輔助分支
- git-flow流程中最主要的五個分支分別為master，release，develop，feature，hotfix。
- 長期分支：master，develop。
- 輔助分支：release，feature，hotfix。、
- 長期分支是相對穩定的分支，所有被認可的提交最終都要合并到這兩個分支上。
- 輔助分支是工作需要臨時開的分支，在完成他們的工作之后通常是可以刪除的。
分支概述
- master：對外發布產品使用的分支，該分支的提交必須是最接近對外上線的版本，不允許在該分支上進行開發，要始終保持該分支的穩定。
- develop：內部開發產品所用的分支，該分支的最新提交必須是一個相對穩定的測試版本，同樣地，不允許在該分支上面進行開發
- feature：新功能分支，每個新的功能都應該創建一個獨立的分支，從develop分支派生出來，功能開發完成之后合并到develop分支，不允許功能未開發完成便合并到develop分支。
- release：發布前的測試分支，一旦開發的功能滿足發布條件或者預定發布日期將近，應該合并所有的功能分支到develop分支，并在develop分支開出一個release分支，在這個分支上，不能在添加新的功能，只能修復bug，一旦到了發布日期，該分支就要合并到master和develop分支，并且打出版本的標簽。
-
hotfix：修復分支，在master上創建的分支，用于對線上的bug的修復，修復問題后，它應該合并回master和develop分支，然后在master分支上打一個標簽。
3.開發流程
3.1 創建遠程倉庫，并拉到本地
創建遠程倉庫的時候默認是創建master分支的，因此拉下來的項目也處于master分支。
$ git clone ...
3.2 創建develop分支
因為master分支上面是不允許進行開發的，創建長期開發分支develop
//創建方式一
//遠程倉庫先創建分支,再本地創建分支,并關聯遠程分支
//實現方式一
$ git checkout -b develop
$ git branch --set-upstream develop/origin develop
//實現方式二
$ git checkout -b develop origin/develop //創建的同時就關聯遠程倉庫
//如果報錯,執行下面命令,在輸入該命令
$ git fetch
//實現方式三
git fetch origin develop:develop
git branch --set-upstream-to=origin/develop develop
//創建方式二
//本地創建分支,再推送到遠程倉庫
$ git checkout -b develop
$ git push origin develop:develop
- 開發負責人本地創建develop分支，并推送到遠程。
- 其他團隊人員克隆后拉取develop分支，此時建議采用實現方式三拉取下來，本地創建分支并關聯遠程倉庫。
3.3 開發新功能
- 假如開發新功能a，在develop分支創建新功能分支a
$ git checkout develop
$ git checkout -b feature/a
- 如果有必要，將該功能分支推送到遠程
$ git push origin feature/a:feature/a
- 如果有必要，成員可將該分支拉下來
$ git fetch origin feature/a:feature/a
3.4 完成新功能
- 新功能完成之后需要將feature分支合并到develop分支，并push到遠程倉庫(在push之前，建議先pull一下，將本地的develop分支內容更新到最新版本，再push，避免線上版本與你commit時候文件內容產生沖突)
$ git checkout develop
//-no-ff 參數可以保存feature/a分支上的歷史記錄
$ git merge --no-ff feature/a
$ git push origin develop
- 合并完成之后，確定該分支不再使用，則刪除本地和遠程上的該分支
$ git branch -d feature/a
$ git push origin --delete feature/a
3.5 測試新版本
當新功能基本完成之后，我們要開始在release分支上測試新版本，在此分支上進行一些整合性的測試，并進行小bug的修復以及增加例如版本號的一些數據。版本號根據 master 分支當前最新的tag來確定即可，根據改動的情況選擇要增加的位
- 開發布分支
//在develop分支中開
$ git checkout -b release/1.2.0
//將分支推送到遠程(如果有必要)
$ git push origin release/1.2.0:release/1.2.0
- 保證本地的release分支處于最新狀態
//將本地的release分支內容更新為線上的分支
$ git pull origin release/1.0.0
- 制定版本號
//commit 一個版本，commit的信息為版本升到1.2.0」
//git commit -a相當于git add . 再git commit
$ git commit -a -m "Bumped version number to 1.2.0"
- 將已制定好版本號等其他數據和測試并修復完成了一些小bug的分支合并到主分支
//切換至主要分支
$ git checkout master
//將release/1.2.0分支合并到主要分支
$ git merge --no-ff release/1.2.0
//上tag
$ git tag -a "1.2.0" HEAD -m "新版本改動描述"
- 將release分支合并回開發分支
//切換至開發分支
$ git checkout develop
//合并分支
$ git merge --no-ff release/1.2.0
- 推送到遠程倉庫
//將開發分支推送到遠程
$ git push origin develop
//將master分支推送到遠程
$ git push origin master
- 刪除分支
$ git branch -d release/1.2.0
$ git push origin --delete release/1.2.0
3.6 修補線上Bug
- 此修復bug針對的是線上運行的版本出現了bug，急需短時間修復，無法等到下一次發布才修復，區別于開發過程中develop上的bug，和測試過程中的release上的bug，這些bug，在原分支上改動便可以。
- 在master根據具體的問題創建hotifix分支，并推送到遠程
git checkout master
git checkout -b hotfix/typo
git push origin hotfix/typo:hotfix/typo
- 制定版本號，一般最后位加1
//commit 一個版本，commit的信息是版本跳
$ git commit -a -m "Bumped version number to 1.2.1"
- 修正后commit并將本地的hotfix分支更新為線上最新的版本
$ git commit -m "..."
$ git pull origin hotfix/typo
- 將剛修復的分支合并到開發分支和主分支
//切換到開發分支
$ git checkout develop
//合并
$ git merge --no-ff hotfix/typo
//切換到主要分支
$ git checkout master
//將hotfix分支合并到主要分支
$ git merge --no-ff hotfix/typo
//上tag
$ git tag -a "1.2.1" HEAD -m "fix typo"
- 刪除修補分支
4.命名約定
- 主分支名稱：master
- 主開發分支名稱：develop
- 新功能開發分支名稱：feature-.../feature/...，其中...為新功能簡述
- 發布分支名稱：release-.../release/...，其中...為版本號。
- bug修復分支名稱：hotfix-.../hotfix/...，其中...為bug簡述。
5.附加Git的沖突
- 當我們需要將本地的分支push到遠程的時候，舉例：當我們新功能開發完成之后，我們合并到develop分支，要將develop分支push到遠程的時候，此時如果遠程的develop分支的內容有更新，我們就需要使用git pull命令將本地的develop分支更新到最新的版本，再推送，否則會產生沖突，無法推送。
- 第一種情況下的pull操作可能也會產生沖突，如果我們本地修改和新commit的內容修改了同一個文件同個位置，此時就應該進行開發者間協商。
- 當我們合并分支的如果兩個分支同時修改了同個文件同個位置時候也會產生沖突，此時需要進行手動解決沖突。
歡迎關注本人博客：https://allen-yu.com/
