git flow使用和規範

git-flow是git非常流行的工作流程。

什麼是git-flow

安裝 git-flow後有一些擴展命令。這些命令會在一個預定義的順序下自動執行多個操作。

git-flow 並不是要替代 Git，它僅僅是把標準的 Git 命令用腳本組合了起來。

嚴格來講，你並不需要安裝什麼東西就可以使用 git-flow 工作流程。你只需要瞭解，哪些工作流程是由哪些單獨的任務所組成的，並且附帶上正確的參數，以及在一個正確的順序下簡單執行那些對應的 Git 命令就可以了。

當然，如果你使用 git-flow 腳本就會更加方便了，你就不需要把這些命令和順序都記在腦子裡。

安裝 git-flow

使用Homebrew安裝

brew install git-flow

分支的模式

git-flow 模式會預設兩個主分支在倉庫中：

• master 只能用來包括產品代碼。你不能直接工作在這個 master 分支上，而是在其他指定的，獨立的特性分支中（這方面我們會馬上談到）。不直接提交改動到 master 分支上也是很多工作流程的一個共同的規則。
• develop 是你進行任何新的開發的基礎分支。當你開始一個新的功能分支時，它將是_開發_的基礎。另外，該分支也彙集所有已經完成的功能，並等待被整合到 master 分支中。
• 支援性分支Feature branches: 開發新功能都從 develop 分支出來，完成後 merge 回 develop
• Release branches: 準備要 release 的版本，只修 bugs。從 develop 分支出來，完成後 merge 回 master 和 develop
• Hotfix branches: 等不及 release 版本就必須馬上修 master 上線的情況。會從 master 分支出來，完成後 merge 回 master 和 develop

這兩個分支被稱作為 長期分支。它們會存活在項目的整個生命週期中。而其他的分支，例如針對功能的分支，針對發行的分支，僅僅只是臨時存在的。它們是根據需要來創建的，當它們完成了自己的任務之後就會被刪除掉。

功能開發

開始新功能

$ git flow feature start xxx

git-flow 會創建一個名為 “feature/xxx” 的分支（這個 “feature/” 前綴 是一個可配置的選項設置）

完成一個功能

$ git flow feature finish xxx

“feature finish” 命令會把我們的工作整合到主 “develop” 分支中去。

之後，git-flow 也會進行清理操作。它會刪除這個當下已經完成的功能分支，並且換到 “develop” 分支。

創建 release

當 “develop” 分支的代碼已經是一個成熟的 release 版本時，這意味著：第一，它包括所有新的功能和必要的修復；第二，它已經被徹底的測試過了。如果上述兩點都滿足，那就是時候開始生成一個新的 release 了：

$ git flow release start 1.1.5

release 分支是使用版本號命名的。這是一個明智的選擇，這個命名方案還有一個很好的附帶功能，那就是當我們完成了release 後，git-flow 會適當地_自動_去標記那些 release 提交。

有了一個 release 分支，再完成針對 release 版本號的最後準備工作（如果項目裡的某些文件需要記錄版本號），並且進行最後的編輯。

完成 release

git flow release finish 1.1.5

這個命令會完成如下一系列的操作：

1. 首先，git-flow 會拉取遠程倉庫，以確保目前是最新的版本。
2. 然後，release 的內容會被合併到 “master” 和 “develop” 兩個分支中去，這樣不僅產品代碼為最新的版本，而且新的功能分支也將基於最新代碼。
3. 為便於識別和做歷史參考，release 提交會被標記上這個 release 的名字（在我們的例子裡是 “1.1.5”）。
4. 清理操作，版本分支會被刪除，並且回到 “develop”。

從 Git 的角度來看，release 版本現在已經完成。依據你的設置，對 “master” 的提交可能已經觸發了你所定義的部署流程，或者你可以通過手動部署，來讓你的軟件產品進入你的用戶手中。

hotfix

修復線上問題

創建 Hotfixes

$ git flow hotfix start missing-link

這個命令會創建一個名為 “hotfix/missing-link” 的分支。因為這是對產品代碼進行修復，所以這個 hotfix 分支是基於 “master” 分支。
這也是和 release 分支最明顯的區別，release 分支都是基於 “develop” 分支的。因為你不應該在一個還不完全穩定的開發分支上對產品代碼進行地修復。

就像 release 一樣，修復這個錯誤當然也會直接影響到項目的版本號！

完成 Hotfixes

在把我們的修復提交到 hotfix 分支之後，就該去完成它了：

$ git flow hotfix finish missing-link

這個過程非常類似於發佈一個 release 版本：

• 完成的改動會被合併到 “master” 中，同樣也會合併到 “develop” 分支中，這樣就可以確保這個錯誤不會再次出現在下一個 release 中。
• 這個 hotfix 程序將被標記起來以便於參考。
• 這個 hotfix 分支將被刪除，然後切換到 “develop” 分支上去。

還是和產生 release 的流程一樣，現在需要編譯和部署你的產品（如果這些操作不是自動被觸發的話）。

總結

git-flow 並不會為 Git 擴展任何新的功能，它僅僅使用了腳本來捆綁了一系列 Git 命令來完成一些特定的工作流程。
其次，定義一個固定的工作流程會使得團隊協作更加簡單容易。無論是一個 “版本控制的新手” 還是 “Git 專家”，每一個人都知道如何來正確地完成某個任務。

記住，使用 git-flow 並不是必須的。當積攢了一定的使用經驗後，很多團隊會不再需要它了。當你能正確地理解工作流程的基本組成部分和目標的之後，你完全可以定義一個屬於你自己的工作流程。

mac中使用git flow常用代碼

Git flow普通BUG流程:

# 進入克隆倉庫(上面有方法) clone
cd /git/woyaoquan
# 初始化版本流程控制
git checkout -b develop origin/develop
# 初始化工作目錄(一直回車即可)
git flow init 
# 開始創建新的需求分支,目的修改image
git flow feature start editimage #這時項目會自動切換 feature/editimage分支
# 更改部分代碼後
# git commit -a -m "修改完了"
# 完成開發分支合併develop(自動)
git flow feature finish editimage
# 發佈到遠程開發分支
git push origin develop
 

Git flow 緊急BUG流程(1):

# 拉回release版本
git pull origin release/v1.0
# 切換分支
git checkout release/v1.0
# 修改BUG
# git commit -a -m "修改完BUG,BUG文件+行數"
# 修改完後提交
git push origin release/v1.0

Git flow 緊急BUG流程(2):

git flow hotfix start hfx