Git-Flow 是 Vincent Driessen 在 2010 年提出的一套 Git 分支模型，簡單的說，它有 master 跟 develop 這兩個主要的分支，以及 feature / release / hotfix 這三個支援型分支，至於各個分支的用途看圖片應該就懂了，或是看原文有更詳細的說明。

由於當時大家對如何使用 Git 還處於摸索的階段，所以當這套規範被提出並且大家發現真的滿好用的之後，它很快就被廣泛的接受。

Git-Flow 適合什麼團隊或專案

沒有萬用解法是適合所有團隊的，你應該根據實際情況做出適當調整，況且 Git-Flow 是在 2010 年提出的，經過這麼多年的時空背景早就不一樣了。專案類型、成員對 Git 的熟悉度、產品釋出頻率、成員人數多寡等等因素都會影響到要使用怎樣的開發流程。

那麼誰適合使用 Git-Flow 呢？

  • 它的分支以及操作那麼多，所以我覺得團隊裡至少要有一兩位對 Git 有一定的熟悉度，這樣才清楚要怎麼操作並能夠指導其他成員。
  • 它有多條 feature 分支，代表這個專案會有多人同時開發 feature 或解 bug。
  • 它有一個 hotfix 分支，代表這個專案釋出新版本的速度應該不快，所以在下個版本釋出之前需要透過 hotfix 的做法修補錯誤。

如果你也覺得 Git-Flow 似乎不怎麼適合你們團隊卻又說不出個所以然來，看到這裡心裡應該有一些想法了。可能你們團員都不是很熟悉 Git，或是開發者只有一兩個人，或是專案釋出的速度很快或版本號對你們沒有意義（例如 web 或 backend 開發），那 GitHub Flow 應該會更適合你們。或者你們團隊已經大到一個程度了，也可以考慮看看 Google 跟 Facebook 採用的 Trunk Model。

我們的做法

首先要介紹一下我們的背景資料：

  • 團隊成員對 Git 的操作都有一定的熟悉度
  • 我們開發 iOS app
  • 我們提供 template app 給客戶，有些客戶需要做客製化
  • 我們有在跑 Scrum，大約每六週就會開發並驗收完一個新版本
  • 由於 iOS 需要送審，加上我們客戶很多，所以從內部驗收完到所有客戶上架新版本，大約還要 2-4 週

我們參考了 Git-Flow 並加以調整，最後我們有以下四種分支：master / develop / task / release。

master

master 上的每個 commit 都是正式發行的版本，所以每個 commit 都會打上一個 tag，例如 v1.2.3 或是 v1.2.3-客戶Ａ ，我們把 master 分支當作版本倉庫，需要哪個版本就去 master 或是 tag 找。

develop

develop 上的就是最新的程式碼，每個 commit 都要能夠編譯成功，我們的 nightly-build 就是抓 develop 分支。

task

不管是要做新的 feature 或是要解 issue，對開發者來說都是一種 task，這就是該分支的命名由來。task 分支總是從 develop 長出來，當某個 task 分支通過測試及 code review 之後，它會先 rebase 到最新的 develop，再 --no-ff 的 merge 回 develop，然後這個 task 就可以砍掉了。

release

當該次開發週期要做的任務都告一段落了，我們就會從 develop 開出一條 release 分支，讓其他同仁做測試與驗收，如果測試驗收過程中有找到任何問題，就修在這條 release 分支上；如果很不幸的該次測試驗收的過程特別久，久到我們都開始開新的 task 分支了，那我們就會定期地把最新的 release merge 回 develop，免得累積多了不好合回來。

最後測試驗收都通過，也成功上架 app store 了，我們就會做以下這些事：

  1. 把該 release 分支 merge 回 develop。
  2. 把該 release 分支的所有檔案（除了 .git 資料夾）複製一份出來，切到 master 分支然後把所有檔案（除了 .git 資料夾）都刪除，然後把剛剛複製的檔案搬過來。你沒看錯，我們用直接覆蓋檔案的方式，而不是用 merge 指令，這樣會省掉很多麻煩。
  3. 在 master 分支打上新的 tag。
  4. 把該 release 分支砍掉。

感謝版友補充，第二步也可以用以下指令達成：

git checkout release
git checkout --detach
git reset --soft master
git checkout master
git commit -m "commit message"

或許你會好奇為何沒有 hotfix 分支，這是因為我們新版本釋出週期夠短，與其額外開一個 hotfix，倒不如直接修正在下一版一起送審就好。以上就是我們 iOS 團隊所採用的流程，如果你也喜歡這樣的開發流程，歡迎成為我們的一員！