Git-flow 工作流使用

Euan發表於2020-03-12
Git

背景

要解決的問題：
瘋狂的分支合併操作

兩個開發分支和一個master分支之間相互merge程式碼，易產生程式碼衝突、程式碼覆蓋，導致生產環境上出現bug。

解決的問題

1.讓現有的分支命名更加規範。
2.讓每個分支的作用更加明確
3.減少程式碼合併的衝突，程式碼覆蓋，導致生產環境產生bug

什麼是Gitflow

Gitflow 工作流定義了一個圍繞專案釋出的嚴格分支模型。體現了工作流的經驗和精髓。隨著專案過程複雜化，會感受到這個工作流中深思熟慮和威力！Gitflow工作流沒有用超出功能分支工作流的概念和命令，而是為不同的分支分配一個很明確的角色，並定義分支之間如何和什麼時候進行互動。
優點是清晰可控，使多人專案協作開發更加規範；
缺點是相對複雜，需要同時維護兩個長期分支。

兩種核心分支


主分支(Master)：程式碼庫有且僅有一個主分支。用於部署生產環境的分支，需確保master分支穩定性master分支儲存了正式釋出的歷史屬於只讀唯一分支，新功能提交應該從不直接與master分支互動，只能從其它分支（如develop，hotfix）合併，不能在這個分支上直接修改。需要注意的是，所有在master上的提交應該標記tag。方便追溯
開發主分支(Develop)：基於master分支檢出的平行分支develop分支始終保持最新完成以及bug修復後的程式碼屬於只讀唯一分支，只能從master以外的分支（如feature，hotfix）合併，不能直接在此修改。如果有新的需求應該拉出一個feature分支。

三種臨時（輔助）分支

預釋出(release)分支：基於develop分支檢出，這個分支由測試開發等同學共同參與。該分支只能做一些優化，Bug測試及修復，文件生成和其它面向釋出任務的臨時分支。完成Release後，最終會先被合併到master（釋出新版本），打TAG標籤，再被合併到develop，最後可選刪除命名規則：推薦為release
補丁分支(hotfix)分支：，基於master分支檢出，用於對線上釋出的版本進行BUG修復。我們需要建立一個Hotfix, 屬於臨時分支，完成Hotfix後，我們合併回Master和Develop分支。打TAG標籤，可選刪除。命名規則：推薦為hotfix-或hotfix/，如hotfix-1.0.1

功能(feature)分支：這個分支主要是用來開發一個新的功能，一旦開發完成，我們合併回Develop分支進入下一個Release。

這三種分支都屬於臨時性需要，使用完以後，應該刪除，使得程式碼庫的常設分支始終只有master和develop。

分支釋出


一旦develop分支上有了做一次釋出的足夠功能或者說快到了既定的釋出日，就從develop分支上fork一個釋出分支（Release）。 新建的分支用於開始釋出迴圈，所以從這個時間點開始之後新的功能不能再加到這個分支上—— 這個分支只應該做Bug修復、文件生成和其它面向釋出任務。 一旦對外發布的工作都完成了，釋出分支合併到master分支並分配一個版本號打好Tag。 另外，這些從新建釋出分支以來的做的修改要合併回develop分支。(最後再刪除Release分支)
使用一個用於釋出準備的專門分支，使得一個團隊可以在完善當前的釋出版本的同時，另一個團隊可以繼續開發下個版本的功能。 這也打造定義良好的開發階段

Git Flow流程示例程式碼

1，建立develop分支
#從master拉出develop分支
#可選，獲取最新版本。git pull origin master
git checkout -b develop master
#釋出develop分支
git push -u origin develop
2，建立feature分支
#從develop拉出feature_v1.0功能分支
#可選，獲取最新版本。git pull origin develop
git checkout -b feature_v1.0 develop
#釋出feature_v1.0分支
git push -u origin feature_v1.0
#在feature_v1.0上開發一些功能
3，完成feature，合併到develop分支
#develop分支獲取最新
git pull origin develop
#切換到develop分支
git checkout develop
#從feature分支合併到develop分支
git merge --no-ff feature_v1.0
#刪除feature分支，也可以不刪除
git branch -d feature_v1.0
4，開始release
#從develop拉出一個release分支
#可選，獲取最新版本。git pull origin develop
git checkout -b release_v1.0 develop
#fix bugs
5，完成release，合併到master分支和develop分支，在master打上tag標記
#合併到master
git checkout master
git merge --no-ff release_v1.0
#在master打tag標記
git tag release1.0 master
git push --tags
#合併到develop
git checkout develop
git merge --no-ff release_v1.0
6，開始hotfix
#從主線master拉出一個hotfix分支
#可選，獲取最新版本。git pull origin master
git checkout -b hotfix_v1.0.1 master
7，完成hotfix，合併到master和develop，並在master上打tag。
#合併hotfix_v1.0.1到master
git checkout master
git merge --no-ff hotfix_v1.0.1
#在master打上tag
git tag hotfix1.0.1 master
git push --tags
#合併hotfix_v1.0.1到develop
git checkout develop
git merge --no-ff hotfix_v1.0.1

Git Flow工具

SourceTree
Tower

使用SourceTree建立工作流


切到develop分支。點選git工作流，選擇建立新的功能

輸入功能名（特性分支名）點選確定即可

如果下圖，我們就建立好了featrue。並從develop分支切到了feature。至此用sourcetree工具就建立好了一個feature支。我們就可以在這個分支上愉快的開發了。

使用Tower建立工作流

1，點選選單欄上的git-flow —->configure git-flow在彈出圖中直接點選configure按鈕即可
2，再次點選選單欄上的git-flow按鈕彈出如下圖。選擇start feature

輸入特性分支名feature_1 點選start feature即可

如下圖，最終我們用sourcetree建立的feature 和tower建立的feature_1都已建立。

分支命名規範
feature分支：以”feature_”開頭，如feature_v1.1
release分支：以”release_”開頭，如release_v1.1
hotfix分支：以”hotfix_”開頭，如hotfix_20160112
tag標記：如果是release分支合併，則以”release_”開頭。如果是hotfix分支合併，則以”hotfix_”開頭。
master分支每次提交都要打tag，release tag：如release_v1.1，hotfix tag：如hotfix_20160112
命名都統一採用小寫。

合併程式碼
merge這裡不展開詳細講解，簡要講解一下rebase 使用
rebase 和 merge 的基本原則：
1下游分支更新上游分支內容的時候使用 rebase
2上游分支合併下游分支內容的時候使用 merge
3更新當前分支的內容時一定要使用 –rebase 引數
例如現有上游分支 master，基於 master 分支拉出來一個開發分支 develop，在 develop 上開發了一段時間後要把 master 分支提交的新內容更新到 develop 分支。此時切換到 develop 分支，使用 git rebase master等 develop分支開發完成了之後，要合併到上游分支 master 上的時候，切換到 master 分支，使用 git merge develop 。
feature分支和並develop分支也同樣應該如此操作。下面給出Git Flow工具演示。

Tower使用。

feature_1分支和並develop分支，切到feature_1分支，選中develo分.點選選單欄上的Rebase按鈕即可

注意:

不要在公共分支使用rebase（如在master分支上rebase develop分支的程式碼，或rebase分支featrue的程式碼）
本地和遠端對應同一條分支,優先使用rebase,而不是merge

丟擲問題:

為什麼不要再公共分支使用rebase?
因為往後放的這些 commit 都是新的,這樣其他從這個公共分支拉出去的人，都需要再 rebase,相當於你 rebase 東西進來，就都是新的 commit 了
一旦分支中的提交物件釋出到公共倉庫，就千萬不要對該分支進行變基操作。
因為不管是git rebase 還是git rebase ,都重置了提交的SHA-1校驗和，當你將本地變基後的提交推送到遠端後，別人從伺服器同步程式碼時，由於相同的內容卻有不同的SHA-1校驗值，因此會再此進行一次合併，於是就會有兩個作者、commit資訊完全相同的提交，但是SHA-1校驗值不同，這無疑會帶來麻煩。
因此，如果把變基當成一種在推送之前清理提交歷史的手段，而且僅僅變基那些尚未公開的提交物件，就沒問題。如果變基那些已經公開的提交物件，並且已經有人基於這些提交物件開展了後續開發工作的話，就會出現叫人沮喪的麻煩。

合併多次commit操作:

1 git rebase -i develop
2 修改最後幾次commit記錄中的pick 為squash
3 儲存退出,彈出修改檔案,修改commit記錄再次儲存退出(刪除多餘的change-id 只保留一個)
4 git add .
5 git rebase –continue
遴選：
將2分支上的某些commit提交到3分支上：

  1. 切到3分支上
  2. 選中2分支上需要抽取的commit，按shift可以多選
  3. 點選遴選
  4. 如果遇到衝突，解決衝突，並標記已解決即可
  5. 提交

    注意：

    一次遴選過後，想要繼續遴選，需要開啟終端，執行git cherry-pick –quit 命令才可繼續遴選
    k按Enter即可。

參考及擴充套件閱讀

https://www.cnblogs.com/wish123/p/9785101....
http://danielkummer.github.io/git-flow-che...

本作品採用《CC 協議》，轉載必須註明作者和本文連結

相關文章