Node.js-Backend見聞錄(03)：關於Git(三)-git flow

前言

承接上篇關於Git(二)-branch，該篇分享會針對「git flow」來介紹git。

什麼是git flow?

「git flow」就是一個透過git來實現系統開發的流程。由於git可以透過branch來開立許多分支，若是能透過branch來掌控開發流程，則能在系統開發上事半功倍。且若是越多人一起協同開發一個專案，就更是明顯（但如果沒有事前討論好branch的規則，造成麻煩的程度也是…非常可怕）。

這邊將透過由Vincent Driessen所寫的A successful Git branching model來做介紹。

在文章中，作者將branch的分支情況分為main branchches及supporting branches兩種，下述我們將先介紹這部分：

Main branches

• master
  當開發的系統要上線時通常會使用該分支去發表。
  但若有非常緊急需要修復的bug，會從這分出hotfixes的分支。

• develop
  專注於開發的分支，會從這分支中衍生出其他supporting branches的分支。

Supporting branches

• hotfixes
  在master分支中若有緊急須修復的bug(等不及在release分支處理)可以挪到hotfixes分支來處理，之後在將修復好的檔案merge到master及develop的分支。

• feature
  每當有個新功能需要開發，就從develop分支中衍生出新的分支。且完成功能後就能merge到develop的分支上。

• release
  當develop開發到一定程度且僅剩些bug就可以轉移到release分支中，之後在將修復好的檔案merge到master及develop的分支。

那該使用什麼git指令才能建構成像A successful Git branching model中，所提到的情境？這邊我們將情境設為下圖的樣子來說明：

new branch: A, C, F, J

$ git checkout -b develop //想新增的branch名稱
Switched to a new branch 'develop'

commit: B, D, G

$ git add <fileName>
$ git commit -m "<commitInfo>"

merge: E, H, K

$ git checkout develop　// 轉移到該branch
Switched to branch 'develop'
$ git merge --no-ff feature //想合併的branch
Merge made by the 'recursive' strategy.

這邊比較特殊的是在git merge後面加入了--no-ff的指令。先假設情境如下：

A //branch 1
 \     
  B---C //branch 2

假設在branch 1後面沒有新增任何commit，且開立branch 2後想要結合C的節點就會變成這種情形：

A---B---C //branch 1 / branch 2

但為了要確保在merge後會有節點D出現，可以使用git merge --no-ff的指令來達成。

A-------D //branch 1
 \     /
  B---C //branch 2

merge, tag: I, L

在這邊較為特別的是除了git merge --no-ff指令外，還多加了git tag的指令。這是因為在master分支當中，都算是可以直接上線的版本。但如果增加一個版號的標誌，將有助於辨識整個系統其上線版本的演進。

在git tag指令中的-a表示給予tag的說明，而後面的-m則是給予commit的說明。如果要顯示整個專案中曾經有使用過的版號，則使用git tag指令就可以達成。

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfixes
Merge made by the 'recursive' strategy.
$ git tag -a v1.5 -m 'version 1.5'
$ git tag
v1.0
v1.5

在完成之後，如果想看圖形化的git長什麼樣子，可以輸入git gitk --all指令來呈現，就可以看到各個brunch之間其commit是怎麼做交集的。

小結

當然，這個情境是仿照A successful Git branching model文章中的圖來進行，但並不是所有的專案或系統都適用。若要找出屬於該專案合適的git flow還是建議跟協同合作開發的夥伴進行溝通，畢竟經由溝通過後的流程才比較適合當下的開發情境。

以及，像些branch的規則，不管是命名規則還是程式的設計形式，都在事前訂立也比較好應對在開發過程中所遇到的問題。

在下篇分享中將介紹些關於在git中「查詢歷程」的基本指令。

參考資料

A successful Git branching model