Git 分支管理實戰：從基礎操作到 Gitflow 策略

– 10 分鐘閱讀

在現代軟體開發流程中，有效的版本控制是確保團隊協作順暢與專案品質穩定的基石。其中，Git 的分支（Branch）機制扮演著至關重要的角色，它不僅提供開發工作的隔離環境，更是實現平行開發、功能實驗與風險控管的核心工具。本文將從基礎實踐出發，逐步解析一個完整的分支開發週期，從創建獨立的功能分支、進行程式碼變更，到透過合併請求（Pull Request）進行團隊審查，最終安全地將變更整合回主線。在此基礎上，我們將進一步探討 Gitflow 這一廣泛應用的進階分支管理模型。透過剖析其定義的 master、develop、feature、release 與 hotfix 等多種分支類型及其互動規則，闡明此結構化策略如何為複雜專案的生命週期管理提供一套清晰且可靠的運作框架。

深入實踐：Git 分支創建、推送與合併流程

本節將透過一個具體的操作流程，詳細闡述如何在 Git 中創建、管理和合併分支，並結合現代協作平台（如 Azure DevOps）的合併請求（Pull Request, PR）機制，完成一個完整的開發週期。

創建與管理功能分支

在進行新功能開發或實驗性改動時，創建獨立的分支是標準做法，這能確保主線程式碼的穩定。

  1. 創建新分支: 假設我們基於 master 分支，需要創建一個名為 Feature1 的新分支來開發某項功能。

    git branch Feature1

    此命令會在當前提交的基礎上創建一個名為 Feature1 的新分支指標。

  2. 切換至新分支: 創建分支後，我們需要切換到該分支才能開始工作。

    git checkout Feature1

    執行此命令後，您的工作目錄將更新為 Feature1 分支的狀態。

  3. 查看分支列表: 可以使用 git branch 命令來查看本地所有分支，並確認當前所在的分支。

    git branch

    輸出的結果會列出所有分支，並用星號 (*) 標示出當前活躍的分支。

  4. 進行程式碼變更與提交: 在新分支上進行所需的程式碼修改、新增文件等操作。完成後，按照標準流程將變更添加到暫存區並創建本地提交。

    git add .
git commit -m "Add feature 1 code"

  5. 推送新分支與提交: 將新創建的分支及其包含的提交推送到遠端倉庫，以便與團隊共享或進行後續的合併請求。

    git push origin Feature1

    此命令會創建一個名為 Feature1 的遠端分支，並將本地的提交同步過去。

協作與合併請求 (Pull Request)

在團隊開發中，直接將功能分支合併到主分支之前，通常會經過程式碼審查流程，這通常通過合併請求（Pull Request, PR）來實現。

  1. 創建合併請求: 在遠端倉庫平台（如 Azure DevOps）上，導航至「Pull Requests」或類似的選項，創建一個新的合併請求。

    • 來源分支: 指定您要合併的分支（例如 Feature1）。
    • 目標分支: 指定您要合併到的分支（例如 master）。
    • 標題與描述: 提供清晰的標題和詳細的描述，說明本次變更的目的和內容。
    • 審查者: 指定需要審查您變更的團隊成員。

  2. 程式碼審查與批准: 審查者會收到通知，並可以查看變更的具體內容（新增、修改、刪除的程式碼）。他們可以提出問題、建議修改，或者直接批准合併請求。

  3. 執行合併: 一旦合併請求獲得批准，通常可以通過平台界面直接執行合併操作。這會將 Feature1 分支的變更合併到 master 分支。

將分支合併回主分支

在合併請求被批准並執行後，我們也可以在本地執行合併操作，確保本地 master 分支與遠端同步。

  1. 切換回目標分支: 首先，切換回您要合併到的目標分支（例如 master）。

    git checkout master

  2. 執行合併: 然後，將包含變更的功能分支（例如 Feature1）合併到當前分支（master）。

    git merge Feature1

    如果合併過程中沒有衝突，master 分支將包含 Feature1 分支的所有變更。如果出現衝突，則需要手動解決後再完成合併。

視覺化分支創建與合併流程

以下圖示展示了從創建分支、進行開發到最終合併的完整流程。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

start

component "Branch Development Cycle" {
  node "Main Branch" as Main
  node "Feature Branch" as Feature

  Main --> Feature : git branch Feature (from Main)
  Feature --> Feature : Develop & Commit on Feature

  Feature --> Main : git merge Feature into Main (after PR approval)
}

stop

@enduml

看圖說話：

此圖示簡潔地呈現了 Git 分支開發與合併的核心流程。圖中的「Main Branch」代表了專案的主線，例如 master 或 develop 分支。當需要開發新功能或進行實驗時，會從「Main Branch」創建一個新的「Feature Branch」（例如 Feature1）。

開發者隨後會在「Feature Branch」上進行程式碼的修改和提交，這部分變更僅限於該分支，不會影響「Main Branch」的穩定性。當「Feature Branch」上的工作完成後，通常會通過程式碼審查（如合併請求）來驗證變更。一旦審查通過，就可以將「Feature Branch」的變更「merge」回「Main Branch」。這樣，主線程式碼就整合了新開發的功能。這個流程確保了開發的隔離性與最終整合的可靠性。

Gitflow 分支策略：結構化開發與協作

在 Git 的眾多分支管理模式中，Gitflow 是一種極為流行且結構化的策略，它為專案的整個生命週期提供了一套清晰的分支定義和工作流程。這套模型旨在提升程式碼的穩定性、促進團隊協作，並簡化發布與維護過程。

Gitflow 的核心分支結構

Gitflow 模型定義了幾種不同用途的分支，它們之間存在明確的創建和合併關係：

  1. master 分支: 此分支始終代表著生產環境中可部署的、最穩定的程式碼版本。開發者不直接在此分支上進行修改，所有變更都必須通過其他分支合併進來。

  2. develop 分支: 這是主要的開發集成分支。所有新功能、Bug 修復等開發工作最終都會合併到此分支。develop 分支代表了即將到來的下一個版本的開發狀態。

  3. 功能分支 (Feature Branches):

    • 創建來源: 從 develop 分支創建。
    • 命名約定: 通常命名為 feature/<功能名稱>，例如 feature/user-authentication。
    • 目的: 用於開發單一的新功能。
    • 合併目標: 功能開發完成後，合併回 develop 分支。

  4. 發布分支 (Release Branches):

    • 創建來源: 從 develop 分支創建。
    • 命名約定: 通常命名為 release/<版本號>，例如 release/v1.2.0。
    • 目的: 準備發布新版本。在此分支上進行最後的測試、Bug 修復、版本資訊更新等準備工作。
    • 合併目標: 發布準備就緒後，合併回 master 分支（標記為生產版本）和 develop 分支（確保 Bug 修復也包含在未來的開發中）。

  5. 熱修復分支 (Hotfix Branches):

    • 創建來源: 從 master 分支創建。
    • 命名約定: 通常命名為 hotfix/<問題描述>，例如 hotfix/critical-login-bug。
    • 目的: 緊急修復生產環境中發現的 Bug。
    • 合併目標: 修復完成後，合併回 master 分支（立即部署修復）和 develop 分支（確保此修復也包含在未來的開發版本中）。

Gitflow 工作流程詳解

Gitflow 的流程圍繞著上述分支的創建、開發和合併展開：

  1. 初始設置: 專案開始時，創建 master 和 develop 分支。
  2. 功能開發: 開發者從 develop 分支創建功能分支 (feature/...)，進行獨立開發，完成後合併回 develop。
  3. 版本準備: 當 develop 分支積累了足夠的新功能，準備發布時，從 develop 創建一個發布分支 (release/...)。在此分支上進行最後的測試和微調。
  4. 生產發布: 發布分支準備就緒後，將其合併到 master 分支，並打上版本標籤。同時，將此發布分支的變更也合併回 develop 分支。
  5. 緊急修復: 如果生產環境的 master 分支出現 Bug，則從 master 創建熱修復分支 (hotfix/...)。修復完成後，將其合併回 master 和 develop 分支。

Gitflow 的優勢與考量

優勢:

  • 隔離性: 各類開發（新功能、發布準備、緊急修復）都在獨立的分支上進行，有效避免相互干擾。
  • 穩定性: master 分支始終保持生產就緒狀態，降低了發布風險。
  • 清晰的流程: 為團隊提供了明確的分支管理規範，易於理解和遵循。

考量:

  • 複雜性: 對於小型專案或快速迭代的專案，Gitflow 的分支結構可能顯得過於複雜。
  • 合併衝突: 隨著分支數量的增加和開發週期的延長，合併衝突的機率也可能增加。

視覺化 Gitflow 分支模型

以下圖示展示了 Gitflow 的典型分支結構和工作流程。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

start

node "Gitflow Workflow" {
  component "master" as Master
  component "develop" as Develop

  component "feature/*" as Feature
  component "release/*" as Release
  component "hotfix/*" as Hotfix

  Master -- Develop : Initialisation
  Develop --> Feature : Create Feature Branch
  Feature --> Develop : Merge Feature into Develop

  Develop --> Release : Create Release Branch
  Release --> Master : Merge Release into Master (Production Release)
  Release --> Develop : Merge Release into Develop (Propagate Fixes)

  Master --> Hotfix : Create Hotfix Branch
  Hotfix --> Master : Merge Hotfix into Master (Hotfix Deployment)
  Hotfix --> Develop : Merge Hotfix into Develop (Propagate Fixes)
}

stop

@enduml

看圖說話：

此圖示清晰地描繪了 Gitflow 的核心分支結構與工作流程。圖的頂部是兩個主要的長期分支：「master」代表生產環境的穩定程式碼，「develop」則作為主要的開發集成分支。

從「develop」分支可以創建多個「feature/*」分支，用於開發獨立的新功能。當功能開發完成後，會被合併回「develop」分支。

當準備發布新版本時，會從「develop」分支創建「release/*」分支。這個分支用於最後的測試和準備工作，最終會被合併到「master」（標記為生產版本）和「develop」（確保 Bug 修復同步到未來開發）。

若生產環境的「master」分支出現緊急 Bug，則會從「master」創建「hotfix/*」分支。修復完成後，該分支會被合併回「master」（立即部署修復）以及「develop」（確保 Bug 修正也納入後續開發）。整個圖示展示了一個層次分明、流程規範的版本控制策略，有助於大型專案的穩定開發與維護。

Gitflow 輔助工具

  1. Gitflow 命令列工具: 由 Gitflow 的創始人開發的命令行工具，可以極大地簡化 Gitflow 工作流程中的分支創建和合併操作。通過簡單的命令，即可遵循 Gitflow 的規範創建特定類型的分支（如功能分支、發布分支等）並執行相應的合併操作。

  2. 圖形化 Git 客戶端: 許多圖形化 Git 工具（如 GitKraken、Sourcetree 等）都內建了對 Gitflow 的支援。這些工具通常提供直觀的圖形介面，讓使用者可以通過點擊操作來創建、管理和合併 Gitflow 分支，而無需記憶複雜的命令行參數。例如，Sourcetree 可以配置 Gitflow 的命名約定，並提供按鈕來執行創建分支、合併等操作。

核心概念回顧
  • Git: 一個分散式版本控制系統，用於追蹤程式碼變更。
  • 初始化倉庫: git init 命令用於在本地目錄創建新的 Git 倉庫。
  • 暫存區 (Staging Area): Git 用於準備提交變更的中間區域。
  • 提交 (Commit): 將變更永久記錄到本地倉庫的操作。
  • 遠端倉庫: 團隊共享的程式碼倉庫，通常託管在服務器上（如 GitHub, Azure Repos）。
  • 推送 (Push): 將本地提交上傳到遠端倉庫。
  • 拉取 (Pull): 從遠端倉庫下載最新的變更並合併到本地。
  • 克隆 (Clone): 複製遠端倉庫到本地的完整副本。
  • 分支 (Branch): Git 中用於隔離開發的機制。
  • 合併 (Merge): 將一個分支的變更整合到另一個分支。
  • Gitflow: 一種結構化的分支管理策略，包含 master, develop, feature, release, hotfix 等分支。
看圖說話：

此圖示整合了 Gitflow 的分支模型與輔助工具的支援。圖中的「Core Branches」包含「master」（代表生產環境）和「develop」（代表開發集成）。「Supporting Branches」則列出了「feature/」、「release/」和「hotfix/*」這幾類用於特定開發任務的分支。

圖示清楚地展示了這些分支之間的創建與合併關係，例如從 develop 創建 feature，然後合併回 develop；從 develop 創建 release，再合併到 master 和 develop；從 master 創建 hotfix，再合併回 master 和 develop。

「Tools Assistance」部分強調了命令行工具（如 git-flow）和圖形化工具（如 GitKraken, Sourcetree）在簡化這些操作中的作用。這些工具可以自動化分支的創建、推送和合併過程，並提供視覺化的介面，讓開發者能更直觀地管理複雜的 Gitflow 工作流程。整體而言，圖示傳達了 Gitflow 策略的結構性以及工具如何提升其實施效率。

縱觀現代軟體開發的協作生態，版本控制策略已從單純的技術實踐，演化為形塑團隊效能與專案品質的治理核心。基礎的功能分支流程提供了高度的敏捷性與低流程開銷，適合快速迭代的小型團隊；然而，當專案規模與協作成員擴大時，其缺乏明確結構的特性，可能導致主線不穩與整合風險遽增。

相較之下，Gitflow 以其嚴謹的分支定義，為大型專案提供了無可比擬的穩定性與流程紀律，它明確劃分了開發、發布與維護的邊界，有效降低因協作混亂而產生的技術債。但其代價是更高的複雜度與流程開銷，若盲目套用在追求極致速度的專案上，反而可能成為創新的枷鎖。

未來的趨勢並非在兩者間做出絕對選擇，而是發展出能與 CI/CD 流程深度整合的混合式模型。這些客製化策略將兼具 Gitflow 的結構性優勢與輕量級流程的敏捷性，實現情境適應性的最佳平衡。

玄貓認為，選擇何種分支策略，本質上是一項關乎組織開發成熟度的管理決策。高階管理者應將其視為建構團隊協作框架的基石，而非單純的技術選項，唯有根據專案生命週期、團隊規模與發布節奏做出明智權衡，才能真正將版本控制從工具提升為驅動卓越工程的引擎。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。