前言
Git 可能是对我们日常开发影响最大的软件了。
我们使用 Git，肯定要采用某个工作流来作为我们的开发流程。
不同的开发流程，有不同的适用场景， 没有银弹！
Workflow - 工作流
- Git flow
- GitHub flow
- Trunk-based development
Git flow
下面这幅图广为流传，可能是很多团队默认的 Git 工作流。
这个工作流是 2010 年这篇文章 A successful Git branching model 提出的，距今也有十几年了。
主要特点：
- 分支很多，有多种类型的分支：feature, develop, release, hotfixs
- 多个分支同时长时间存在，并行开发；当合并这些分支的时候，可能要解决大量的合并冲突
- feature 分支需要一段时间才能合并到主干分支，无法做到真正的持续集成&持续发布
- 适合要同时维护多个版本的场景（比如，同一个前端项目，需要同时维护
Android端、iOS端；一个服务端项目，给不同的客户做了定制化开发，需要维护多个版本；现在常见的应用类型是 Web 应用，通常只有一个版本，所以不适用这种工作流）
GitHub flow
GitHub flow is a lightweight, branch-based workflow. The GitHub flow is useful for everyone, not just developers.
For example, here at GitHub, we use GitHub flow for our site policy, documentation, and roadmap.
GitHub flow 是一个轻量级的、基于分支的工作流。
GitHub flow 对每个人都有用，不止是开发者。
主要特点：
- 分支比
Git flow少很多 - 开发新功能，从
master分支拉取feature分支；功能完成后，提交Pull Request，代码审核后再合并到master分支，最后删除feature分支 - 版本管理更简单、更轻量，更符合持续集成的思想
顺着持续集成的思想，如果我们把 GitHub flow 分支模型做得再极致一点：
- 我们不要
feature分支； - 或者把
feature分支只留在本地，不再使用Pull Request而是直接push到远程master 分支；
我们就做到了 Trunk based Development。
Trunk-Based Development
Paul Hammant 在 2013-04-05 发表了文章 What is Trunk-Based Development?。
在这篇文章中提出了 Trunk-Based Development - TBD，基于主干分支开发 的工作流。
主要特点：
- 大部分时间只有一个分支：主干分支
Trunk - 尽量不新建开发分支，任何改动直接提交到主干分支
- 必须新建开发分支的情况下，开发分支最多存活几天，然后要合并到主干分支，最后删除掉开发分支
- 任何代码提交到主干分支时，先在本地构建整个项目；只有构建通过了，才能提交到主干分支
- 分支越少 --> 合并操作就越少 -->代码合并冲突也越少
- 因为只有一个分支（即主干分支），保证了最新代码都在这个分支上，真正做到了持续集成&持续交付
- 适合不需要维护多个版本的开发场景，比如服务端的 Web 应用，基本上只需要维护一个版本
不鼓励在开发分支上长时间开发，再合并到主干分支（冲突很多）：
小团队开发模式：不断提交代码到主干分支
大规模开发模式：在存在时间短的开发分支上开发，然后合并回主干分支
参考资料
- https://nvie.com/posts/a-successful-git-branching-model/
- https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
- https://docs.github.com/en/get-started/quickstart/github-flow
- https://trunkbaseddevelopment.com/
