若您對於 Git 相當熟悉，你應該對於建立分支(Branch) 應該不陌生。依據 GitHub 官方文件定義：分支是一個獨立開發環境，為了避免影響到其他開發環境 (Branch)而設計的。正常情況下，應該會有一個預設的主分支並擁有許多不同的分支，當工作完成，分支可以合併到其他分支。

建立分支

雖然你也能透過 Git 指令/工具建立分支，但這不是我們這次重點，若有興趣可以參考：使用 Git 分支 - 分支和合併的基本用法。我們將透過 GitHub Repo 介面來建立 Branch。如下圖所示，點選左上角分支下拉選單，再搜尋框輸入你要新增的分支名稱 (若有重複則會找到該分支，沒重複則可以建立新分支)，點選下方 Create Branch: [分支名稱] 即可。

建立完成後，可以看見左上角分支為新的名稱。相同的，你可以透過下拉選單，切換分支進行檢視。

分支策略

Git 分支的設計運用其實可以很多元，不僅僅只有避免影響其他環境所建構獨立開發環境。對於多人協同開發與快速交付的目的，Git衍伸出許多分支策略，常見的策略有 GitHub Workflow, Git Flow 與 Forking Workflow。若你的開發團隊有不同的分支策略，可以在不同情境解決不同問題，也歡迎你下面留言分享喔。

GitHub Workflow

GitHub Workflow 我們在第一篇文章內有提到，是一個輕量級、以分支為基礎的工作流程。主要強調 pull request 與合併前部屬，確保問題可以快速解決，也能維持交付品質的方式。

Git Flow

Git Flow 也一組規則，設計用於頻繁更新版本的流程，所建立的分支如下

• Master branch (Main)
• Develop branch (Main)
• Release branch
• Feature branch
• Hotfix branch

因為直接將所有分支畫在同一張圖可能會讓讀者混淆，所以我們逐一說明每個分支的功能與執行方式，首先是 Feature Branch，平時開發人員收到新功能需求時，即開一個分支，待完成後合併回 Develop 分支。

也適用於 Bug 處理，有些組織會見 BugFix Branch，執行方式與 Feature Branch 相同

Hotfix 屬於立即性要修的問題；Bug 屬於可以下次 Release 時要修的問題

當確定新版本釋出時間後，會立即開啟 Release branch，確定在這個版本釋出的功能，接會合併至 Release。非這個版本的功能，繼續合併回 Develop，確保不會有不屬於新版本的內容。

定時將 Release 合併回 Develop 內，確保功能一致，減少衝突

當新版本正式上線時，我們會合併至 Master(Main) 分支，並且建立 Tag (版本)，並合併回 Develop 確保內容一致。

當正式上線發現重要 issue，即從 Master(Main) branch 開分支進行處理，合併回 Master (Main) 進行修復，完成後需要合併回 Develop 確保內容一致

結合上面所有流程，即為下面這張流程圖，提供有興趣的朋友參考

Fork Workflow

GitHub Fork 的定義為複製一份 Repo 到自己帳號底下(像是用叉子拿一分肉到自己盤子)。Forking Workflow 也是 GitHub 主要的使用的方式，主要目的在於：

1. 複製一份 Repo
2. 避免影響原始的 Repo (original repo)
3. 透過 pull request 將變更內容進行合併 (Code review)
4. 任何人皆可以進行

如下圖所示，任何人皆可以 fork 一份 repo 到自己的帳號下，你可以透過 clone/pull/push 方法在本地端建立 repo 進行修改，最後再 pull request 提交自己的貢獻。 Owner 確認沒問題且合乎發展目標，即會同意合併，達成貢獻。

這種流程很適合開源專案，所有人皆可以參與協作並建立 Pull Request，讓專案越來越好。

閱讀完本篇文章，你應該可以從較 High-Level 檢視 Branch 的使用方法與規劃流程，而不是對 Branch 只有 Create, Merge, 解衝突而已。下一篇，我們將介紹建立 Repo 後的 Security 起手式 - 設定 Branch Policy。

若你喜歡我的文章，歡迎分享與追蹤，謝謝 ^_^