本文介绍了作者了解到的三种常见的单仓库的git工作流，它们是:
- Centralized工作流
- 仅使用master一个分支
- Feature Branch工作流
- 使用一个master分支管理稳定版本
- 使用多个feature分支管理需求开发
- Gitflow工作流
- 使用一个master分支管理发布版本历史
- 使用一个develop分支管理开发流程
- 使用多个feature分支管理需求开发
- 使用多个release分支管理版本发布
- 使用多个hotfix分支修复紧急bug
Centralized工作流
这种工作流只使用唯一的master分支
Centralized需求开发的过程
- 拉取远端分支(pull/clone)
- 开发(add, commit)
- 上图中的白色master
- 再次拉取远端分支(fetch)
- 上图中的紫色origin/master
- 合入，处理冲突(rebase)
- 上图中的蓝色master
- 注意这里不使用merge，merge会导致master分支出现类似新branch的分叉行为, 丢失了单分支的简洁性
- 提交修改(push)
Centralized工作流优点
- 简单，对于单人小项目，没有必要考虑太多管理的情况下直接使用，没有问题
- 和SVN的工作流非常相似，方便从SVN迁移到Git的团队做一段时间的缓冲
Centralized工作流缺点
- 太过简单，没有利用好Git的分支特性
Feature Branch工作流
对于这种工作流，开发者需要使用:
- 一个master分支管理稳定版本
- 多个feature分支管理需求开发
Feature Branch需求开发的过程
- 拉取远端分支(pull/clone)
- 从master新建feature分支(checkout -b feature/XXX)
- 开发(add, commit)
- 再次拉取远端分支(fetch)
- 合入，处理冲突(merge)
- 注意这里需要的合入处理冲突是指将feature/XXX合入master，而不是将master合入feature/XXX
- 另外，merge的时候建议使用
--no-ff，保证只产生一个merge commit，原因下面会讲
- 提交修改(push)
Feature Branch工作流优点
该工作流相比于Centralized工作流，更加复杂，利用了Git分支的特性，相比之下，优点有:
- 需求开发的管理更加清晰，有单独的分支
- 由于使用的是不同的分支，可以开启pull request和merge review，通过强制code review提高代码质量
- 需求分支合入master时，只会产生唯一的merge commit(如果merge的时候使用了
--no-ff的话)，这样如果想要把一个feature revert掉，只需要revert唯一的一个commit，而不需要选出有关的commit一个个地revert
Feature Branch工作流缺点
缺点/不足:
- 没有专门用于版本发布的机制
- 版本发布可能涉及到很多非开发的杂事(比如文档编写与生成，项目打包等等)，这些不适合作为feature来开发
- 在该工作流中，没有办法清晰看出哪些commit是发布的版本
- 没有用于紧急修复bug的机制
- 紧急bug修复，也不适合作为feature来开发
Gitflow工作流
这个工作流需要开发者:
- 使用一个master分支管理发布版本历史
- 使用一个develop分支管理开发流程
- 使用多个feature分支管理需求开发
- 使用多个release分支管理版本发布
- 使用多个hotfix分支修复紧急bug
Gitflow需求开发流程(feature分支)
- 拉取远端分支(pull/clone)
- 从develop分支开启新的feature分支(checkout -b feature/XXX)
- 开发(add, commit)
- 再次拉取远端分支(fetch)
- 合入，解决冲突(merge)
- 提交修改(push)
这个流程和feature branch是一致的，只不过把base分支从master改为了develop
注意所有的feature分支都:
- 从develop分支新建而来
- 合入到develop分支而去
Gitflow版本发布流程(release分支)
- 拉取远端分支(pull/clone)
- 从develop分支开启新的release分支(checkout -b release/XXX)
- 版本发布开发(add, commit)
- 包括文档生成，打包等杂事
- 也可以修复小bug
- 但是大的改动必须使用需求开发流程，去新feature分支进行处理，并移动到下个版本上
- 再次拉取远端分支(fetch)
- 合入，解决冲突(merge)
- 这里，需要将release分支同时合入master和develop分支
- 合入master，是为了保存版本发布记录
- 合入develop，是为了后续开发能够兼容该版本
- 比如说在release上修复了小bug，或者添加了文档注释等，都要反映到后续开发上
- 提交(push)
注意所有的release分支都:
- 从develop分支新建而来
- 合入到master和develop分支而去
Gitflow紧急修复bug流程
- 拉取远端分支(pull/clone)
- 从master分支新建hotfix分支(checkout -b hotfix/XXX)
- 开发，修复bug(add, commit)
- 再次拉取远端分支(fetch)
- 合入，解决冲突(merge)
- 这里的合入需要同时合入master和develop，理由同release分支
- 但是理论上合入master分支的时候不应该有冲突，只能在合入develop分支的时候才会有可能冲突
- 提交(push)
注意所有的release分支都:
- 从master分支新建而来
- 合入到master和develop分支而去
Gitflow工作流评价
这里就不放优缺点了，因为Gitflow是目前使用最广，最为流行的git工作流
或许会有一些小的出入，但是各大公司基本上内部都会遵守这样的规则
大小项目，大小团队，都适用gitflow工作流