22.1 集中式工作流
在这种基本的工作流模型中，master 分支包含所有活跃的开发。贡献者需要特别确保在继续开发之前拉取最新的更改，因为此分支会快速变化。每个人都可以访问此仓库，并可以直接向 master 分支提交更改。
可视化表示
这是经典的版本控制系统范式，基于此构建了 Subversion 和 CVS 等旧系统。采用这种工作方式的软件被称为集中式版本控制系统（CVCS）。虽然 Git 可以以这种方式工作，但存在一些明显的缺点，例如需要在每次拉取之前执行合并。团队完全可以这样工作，但频繁的合并冲突解决可能会消耗大量宝贵的时间。
这就是为什么 Linus Torvalds 创建 Git 不是为了作为 CVCS，而是作为分布式版本控制系统（DVCS），类似于 Mercurial。这种新方法的优势在于其他页面上展示的灵活性。
22.2 Gitflow 工作流
最初由 Vincent Driessen 提出，Gitflow 是一种使用 Git 和几个预定义分支的开发工作流。这可以被视为功能分支工作流的一个特例。
核心思想
这种工作流的核心思想是为开发过程中的特定部分保留单独的分支：
master分支：始终包含最新的生产代码。实验性代码不应在此处。develop分支：包含所有最新的开发更改。这些开发更改可以是任何内容，但较大的功能通常保留为它们自己的分支。此处的代码始终在合并到发布之前进行工作。- 热修复分支：用于对
master分支进行小的错误修复，这些错误修复不能等待下一个版本发布。热修复分支从master分支派生，并合并回master和develop分支。 - 发布分支：用于从
develop分支发布新开发到master分支。任何最后时刻的更改（例如更新版本号）都在发布分支中完成，然后合并回master和develop分支。在部署新版本时，master分支应使用当前版本号（例如使用语义版本控制）进行标记，以便于未来参考和轻松回滚。 - 功能分支：为较大的功能保留。这些功能在指定的分支中专门开发，并在完成后与
develop分支集成。专用功能分支有助于分离开发，并能够独立部署完成的功能。
可视化表示
这种工作流的原始表示如下：
22.3 功能分支工作流
功能分支工作流的核心思想是所有功能开发都应在专用分支中进行，而不是在 master 分支中。这种封装使得多个开发人员可以在不影响主代码库的情况下同时开发特定功能。这也意味着 master 分支永远不会包含损坏的代码，这对于持续集成环境来说是一个巨大的优势。
功能开发的封装
功能开发的封装还使得可以利用拉取请求，这是一种围绕分支启动讨论的方式。它们为其他开发人员提供了在功能集成到官方项目之前对其进行验证的机会。或者，如果你在功能开发中途遇到困难，可以打开一个拉取请求，向同事寻求建议。要点是，拉取请求使得团队成员之间可以轻松地对彼此的工作进行评论。
基于 Atlassian 教程。
22.4 GitHub Flow
GitHub Flow 在许多开源项目中非常流行，但不仅限于此。
核心思想
特定位置（GitHub、GitLab、Bitbucket、本地服务器）的 master 分支包含最新的可部署版本。每个开发人员为每个新功能/错误修复/架构更改创建一个分支。
更改发生在该分支上，并且可以在拉取请求、代码审查等中进行讨论。一旦被接受，它们就会被合并到 master 分支。
完整流程
Scott Chacon 的完整流程如下：
master分支中的任何内容都是可部署的。- 为开发新内容，从
master分支创建一个描述性命名的分支（例如：new-oauth2-scopes）。 - 在本地对该分支进行提交，并定期将你的工作推送到服务器上同名分支。
- 当你需要反馈或帮助，或者认为分支准备好合并时，打开一个拉取请求。
- 在其他人审查并批准功能后，你可以将其合并到
master分支。 - 一旦合并并推送到
master，你应该立即部署。
最初在 Scott Chacon 的个人网站上提出。
可视化表示
22.5 叉工作流
这种工作流与本章提到的其他工作流有本质的不同。与其有一个所有开发人员都可以访问的集中式仓库，不如说每个开发人员都有自己的从主仓库分叉的仓库。这样做的好处是开发人员可以将自己的更改推送到自己的仓库，而不是共享仓库，维护者可以在认为合适的时候将更改从分叉的仓库集成到原始仓库中。
这种工作流的可视化表示如下：
