在製作專案時，大多都是與他人共同協作，當一起開發的人越來越多時，就更需要有一套規則或模式來進行合作，以防多人同時合作時，大家都各自照著自己的方式隨便進行，可能會造成合作上的災難，專案也容易混亂不夠清楚。

因此這套有規範的工作流程，在英文裡可以稱作是 " workflow " 或是 " flow " ，意指水流，這裡用來比喻像水流一樣，能夠順暢地流動，不會產生衝突、水花。

常見的開發流程：

1. Git flow
2. GitHub Flow
3. Gitlab Flow

上述三套流程，大致上都有一個共同點，就是他們都是以特性驅動開發 (Feature-driven development，簡稱 FDD)，是一個模型驅動(model-driven)、短期迭代(short-iteration)的過程，過程中會有起點與終點。

起點是需求，先有了需求後，再開啟 Feature branch 或 Hotfix branch ，當完成專案以後，將分支的更新合併到原先的分支上（主分支），出來的分支再被刪除。

Git flow

是最早出現的一套流程，且廣泛被應用。

Git flow 提出不同的分支功能，分別有 master、develop 、hotfix、release、feature 五種分支。

而這五個分支，根據他們的性質，又有其他稱法：

• 長期分支 - master 分支、develop 分支

  原因：因 Master 與 Develop 分支會一直存活在整個 Git flow 裡，並不會被刪除掉。

• 短期分支 - hotfix 分支、release 分支、feature 分支

  原因：當完成專案後，這些更新的版本都會被合併進 Master 或 Develop 分支 ，之後就會被刪除掉。

分支應用情用

Master 分支

master 是當 Git 建立版本控制時，就預設的分支，主要用來放穩定、隨時可上線的版本。

• 永遠處在 production-ready 狀態
• 來源是從其他分支合併過來，開發者不會直接 Commit 到此分支上。
• 因為是穩定版本，所以通常會在 master 分支上的 Commit 貼上「 版本標籤 」。

Develop 分支

作為主要開發的分支，是所有短期分支的基礎分支。

• 最新的下次發佈開發狀態

• Feature 分支從 Develop 分支切出去，當功能完成後，在合併回來 Develop 分支。

• 創建 Develop 分支的指令：

  $ git checkout -b develop master
  

• 當要發布時，在 Master 分支上對 Develop 分支進行合併：

  $ git checkout master # 切換到 master 分支
  $ git merge --no-ff develop # master 分支對 develop 分支進行合併
  

  -no-ff 參數代表不要快轉模式（fast-forward），會額外產生一個 Commit 物件。

--

Hotfix 分支

主要功能是用來進行修復

• 從 Master 分支切出來的。
• 當修復完後，會合併回 Master 分支， 也同時會合併回 Develop 分支。

👉 合併回 Develop 分支的原因：

更新 Develop 分支的版本，避免遇到將 Develop 分支並回 Master 分支時，同樣的問題又出現。

👉 避免直接從 Develop 分支切出 Hoxfix 分支的原因：

Develop 分支為功能開發階段的分支，如果直接從 Develop 分支切 Hotfix 分支，再合併回 Master 分支，可能會造成管理上的問題/災難。

• 建立一個 Hotfix 分支

  $ git checkout -b fixbug-0.1 master
  

  常用 fixbug-* 的形式命名

• 修補結束後，合併到 Master 分支

  $ git checkout master # 切換到 master 分支
  $ git merge --no-ff fixbug-0.1 # 搭配非快轉模式參數合併 hotfix 分支
  $ git tag -a 0.1.1 # 貼上訊息標籤
  

• 同時也要再合併到 Develop 分支

  $ git checkout develop # 切換到 develop 分支
  $ git merge --no-ff fixbug-0.1 # 搭配非快轉模式參數合併 hotfix 分支
  

• 最後再將 Hotfix 分支刪除

  $ git branch -d fixbug-0.1 # 刪除 fixbug-0.1 分支
  

  -d 參數為刪除之意

Release 分支

在 Develop 分支發布正式版本到 Master 分支之前，可以先進行一個預備發布的本版本進行測試。

• 從 Develop 分支切出來

• 完成後需合併到 Master 分支與 Develop 分支

  👉 為何又需要再合併 Develop 分支？

  Master 分支為上限版本，而合併 Develop 分支的原因是為了後續可能 Release 分支上還會偵測到其他問題，所以需與 Develop 分支同步，以防再度出現同樣的問題。

• 建立 Release 分支

  $ git checkout -b release-1.2 develop
  

  release-* 的形式命名

• 修正完成後，合併到 Master 分支

  $ git checkout master # 切換到 master 分支
  $ git merge --no-ff release-1.2 # 合併 release-1.2 分支，使用非快轉模式合併
  $ git tag -a 1.2 # 為新的節點新增訊息標籤
  

• 之後也要記得合併到 Develop 分支上

  $ git checkout develop # 切換到 develop 分支
  $ git merge --no-ff release-1.2 # 合併 release-1.2 分支，使用非快轉模式合併
  

• 兩個長期分支都合併完後，再刪除掉 Release 分支

  $ git branch -d release-1.2
  

Feature 分支

主要用來新增功能的分支。

• 都是從 Develop 分支切出來的，完成後再合併回 Develop 分支。

• 建立一個 Feature 分支

  $ git checkout -b feature-x develop
  

  feature-* 的形式命名

• 功能開發完成後，再將 Feature 分支合併到 Develop 分支上

  $ git checkout develop # 切換到 develop 分支
  $ git merge --no-ff feature-x # 合併 feature-x 分支，使用非快轉模式合併
  

• 同樣完成後，會刪除掉分支

  $ git branch -d feature-x # 刪除 feature-x 分支
  

Git flow 的優缺點

優點：

清晰可控

缺點：

較為複雜，需要同時維護 master 分支與 delevop 分支兩個長期分支。因為通常都以 master 分支當作正式發佈的分支，而 delevop 分支是進行開發的分支，會時常需要切換。

Github flow

Git flow 的簡化版。

• 只有一個長期分支 - master 分支
• 流程：

  1. 根據需求，從 master 分支切出其他分支進行開發。

  2. 開發完成或是需要討論時，向 master 分支發起 pull request 請求（PR）

     GitHub 有 PR 功能，可以用於可能你想幫其他人提供更好的程式碼，就可以發起 PR 請求。

  3. Pull request 請求被接受，後合併到 master ，重新部署後，原先的分支則被刪除。

--

Github flow 的優缺點

優點：

簡單、適用於「持續更新」的產品的開發流程

缺點：

預設情況為 master 為最新的提交版本，但這造成有時可能有指定時間發佈，或是尚須審核，則這時候只有一個 master 分支就會造成困擾，需新建一個 production 分支追蹤線上版本。

Gitlab flow

Git flow 與 GitHub flow 的合併模式流程。

• 原則：以「上游優先」（upsteam first）。意指只認存在一個主要分支 Master 分支，他是其他所有分支的「上游」。只有這隻上游分支採納的代碼變化，才能應用到其他分支。
• 針對不同的開發情況，有兩種情況：
  1. 「持續發布」- 除了 master 分支外，根據不同環境建立對應的分支。並需服從上游到下游一層一層的過關規則。
  2. 「版本發佈」- 每當有一個穩定的版本，就要從 master 分支拉出一個分支。只有修補 Bug 時，才允許將代碼合併到這些分支，並且需要更新小版本號。

沒有哪一種模式的流程比較好，都是根據情況或是各公司的開發模式來決定流程規則。因此這幾種常見的流程都可以仔細研究，對於後續的專案管理上也更好與他人協作。

參考文章：

https://www.ruanyifeng.com/blog/2012/07/git.html

https://www.ruanyifeng.com/blog/2015/12/git-workflow.html