iT邦幫忙

2021 iThome 鐵人賽

DAY 29
3
Modern Web

【Git】從零開始學習 Git - 30 天的學習筆記系列 第 29

Day29|常見的三種工作流程 - Git flow、GitHub Flow 與 Gitlab Flow

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

因此這套有規範的工作流程,在英文裡可以稱作是 " 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 提出不同的分支功能,分別有 masterdevelophotfixreleasefeature 五種分支。

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

  • 長期分支 - 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


上一篇
Day28|將 GitHub 的檔案抓取下來到自己的本地端 - git pull 指令與衝突時的解決方法
下一篇
Day30|Git 學習資源與方式暨完賽心得
系列文
【Git】從零開始學習 Git - 30 天的學習筆記30

尚未有邦友留言

立即登入留言