常见的git工作流

本文首发于我的Github博客

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

  1. Centralized工作流
    • 仅使用master一个分支
  2. Feature Branch工作流
    • 使用一个master分支管理稳定版本
    • 使用多个feature分支管理需求开发
  3. Gitflow工作流
    • 使用一个master分支管理发布版本历史
    • 使用一个develop分支管理开发流程
    • 使用多个feature分支管理需求开发
    • 使用多个release分支管理版本发布
    • 使用多个hotfix分支修复紧急bug

Centralized工作流

常见的git工作流_第1张图片
这种工作流只使用唯一的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工作流

常见的git工作流_第2张图片
这个工作流需要开发者:

  • 使用一个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工作流

你可能感兴趣的:(good,practice,git)