GitHub Branch 策略 - 哪一种方式适合你?

若您对於 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。

若你喜欢我的文章，欢迎分享与追踪，谢谢 ^_^