常见的git工作流

本文首发于我的Github博客

本文介绍了作者了解到的三种常见的单仓库的git工作流，它们是:

1. Centralized工作流
   • 仅使用master一个分支
2. Feature Branch工作流
   • 使用一个master分支管理稳定版本
   • 使用多个feature分支管理需求开发
3. 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工作流