gitflow工作流

微信扫一扫,分享到朋友圈

gitflow工作流

1. 工作流程

项目开始(master、develop)

  1. 开发组长,基于master主干创建develop分支。master和develop就作为仓库的两个主干,并且将它们的加权限限制,只有管理员可修改。

开发阶段(master、develop、feature)

  1. 基于develop创建多个feature分支(如:feature/login),对应功能模块的开发人员,基于该分支开发新功能。
  2. 开发人员,测试新功能完成以后,在git上发起pull request把代码合并到到develop分支上。
  3. 开发组长,在确认代码没有问题后,通过该pull request 的合并请求。当所有的功能都开发完了,所有的feature分支都合并到develop上。

测试阶段-开始测试(master、develop、release)

  1. 开发组长,基于develop分支创建一个release预发布分支(如:release/1.0.0),并设置release分支只有管理员有权限修改。
  2. 基于release/1.0.0分支的代码进行测试。

测试阶段-测试中(master、develop、release、bugfix)

  1. 当测试发现bug时,基于当前release/1.0.0分支创建bugfix分支(如:bugfix/问题编号),开发人员基于该bugfix分支进行bug修复。
  2. 开发人员在bug修复后,向release/1.0.0分支提交 pull request 申请。
  3. 开发组长在确认bug修复完成后,通过该pull request 的合并请求。所有bug修复完成后,当前release版本下,所有bugfix分支都合并到release/1.0.0上。

测试阶段-测试完毕(master、develop、 tag

  1. 开发组长发起pull request,把release/1.0.0代码合并到到master分支上。
  2. 基于master分支创建一个里程碑版本(tag)名为1.0.0-Release,并且在github上发布一个Release,可以将当前master代码以及相关包存档。
  3. 原则上只需保留master、develop两个分支,和1.0.0-Release里程碑版本(tag)。删除完成使命的其他分支:多个feature分支、多个bugfix分支和release/1.0.0。

线上bug-master(master、develop、hotfix)

  1. 线上版本出现bug,可以基于最新版本(master)进行修复,可以基于master创建hotfix分支(如:hotfix/问题编号),开发人员基于该hotfix分支进行bug修复。
  2. 开发人员在bug修复后,向master分支提交 pull request 申请。
  3. 开发组长在确认bug修复完成后,通过该pull request 的合并请求。基于master分支创建一个里程碑修复版本(tag),假如当前版本为1.2.0-Release,则修复版本为1.2.1-Release。

线上bug-历史版本(master、develop、 tag 、hotfix)

  1. 用户基于某个里程碑版本tag(如:1.0.0-Release)提出bug,创建一个issue。如果master版本已经发布到1.0.0以后了(如:1.2.0-Release),但是该bug修复只能基于历史的1.0.0修复,就需要基于该里程碑版本(tag)1.0.0-Release,创建一个release/1.0.1分支,和hotfix分支(如:hotfix/问题编号),开发人员基于该分支修复bug。
  2. 开发人员在bug修复后,向release/1.0.1分支提交 pull request 申请。
  3. 开发组长在确认bug修复完成后,通过该pull request 的合并请求。基于release/1.0.1分支创建一个里程碑修复版本(tag),名为1.0.1-Release。

示例代码(release/*)

# 开始 release
git checkout -b release/0.0.1 develop
# 完成 release
git checkout master
git merge --no-ff release/0.0.1
git push
git checkout develop
git merge --no-ff release/0.0.1
git push
git branch -d release/0.0.1
git push origin --delete release/0.0.1
# 合并master/devlop分支之后,打上tag
git tag -a v0.1.0 master
git push --tags

2. 分支说明

master

  • master 分支为主分支,用于部署生产环境,需要确保master分支的稳定性。
  • 此分支属于只读分支,只能从 release或hotfix 分支合并过来,任何时候都不能在此分支修改代码。
  • 所有向master分支的推送,都要打上tag标签记录,方便追溯。
  • 此分支只能前进,不能有回退操作。

develop

  • develop 为开发环境主干分支,基于 master 分支检出。
  • 此分支为只读分支,只能从master、release、feature分支合并过来,任何时候都不能在此分支修改代码。
  • 此分支只能由开发人员提交 pull request(需要 code review),或者由管理员 merge release 分支。
  • 在一个 release 分支没有创建出来时,develop 分支不能合并不包含 release 功能范围的 feature 分支。develop 分支在特殊情况下可以回退版本。

release/ *

  • release 分支为预上线分支,基于 develop 或 master 分支检出。用于准备发布新阶段版本或者修复线上bug版本。
  • 此分支用于上线前bug测试,文档生成和其他面向发布任务。
  • 此分支属于只读分支,只能由 master 分支或者 develop 分支检出,或者从 bugfix 分支、hotfix 分支合并过来,任何时候都不能在此分支修改代码。
  • 此分支属于临时分支,在发布提测阶段,会以 release 分支代码为基准提测。当 release 分支测试验证通过后,最终会先被合并到 master 分支(发布新版本或者修复线上bug,要打tag标签),再被合并到 develop 分支(使其与 master 分支保持一致),最后删除此分支。
  • 命名:release/<版本号>(例:release/1.0.0)

feature/ *

  • feature 分支为功能开发分支,由开发人员基于 develop 分支创建 feature/<功能模块> 分支。
  • 此分支用于新功能开发,一个 feature 分支最大粒度只能到模块。
  • 此分支为临时分支,最终会被合并到 develop 分支(新增功能),或者删除(放弃功能)。
  • 此分支通常仅存在于开发人员本地存储库中,而不存在与远程origin。
  • 一个新功能开发完成后,且在开发集成环境自测通过、单元测试通过、Sona扫描通过后,才能向 develop 分支提交 pull request (需要 code review)。

bugfix/ *

  • 预上线 bug 修复分支,基于 release 分支检出。
  • 此分支用于上线前bug修复。
  • 此分支属于临时分支,当提测阶段中存在 bug 需要修复,由开发人员基于 release 分支创建 bugfix/<bug名字> 分支,然后在 bugfix/<bug名字> 分支进行修复 bug 。 bug 修复完成后,并且在开发集成环境自测通过、单元测试通过、Sona扫描通过后,再向 release 分支提交 pull request 申请。bug修复完成 release 分支测试通过之后可删除此分支。

hotfix/ *

  • 生产环境 bug 修复分支,基于 master 分支检出。
  • 属于临时分支,当生产环境出现 bug ,管理员基于 tag 创建 hotfix/<bug名字> 分支、 release/<版本号> 分支,由开发人员在hotfix分支修复bug,修复完成后,并且在开发集成环境自测通过、单元测试通过、Sona扫描通过后,再向 release 分支提交 pull request 申请。bug修复完成上线之后可删除此分支。

总结

  • 只有 master 和 develop 两个分支是主干分支,一直存在的。其他分支都是功能性分支,在完成历史使命后会,可以被删除。
  • master、develop 和 release/* 三种分支是被锁住的只读分支,只有管理员有权限修改。只能合并,不能直接提交,其他人想要合并只能提交 pull request。

3. 版本号

在前文很多地方都涉及到版本号,例如:release/* 分支、提交tags和发布Release版本等,版本号的命名也需要有一定的规范。

版本号(公开)

对外正式发布的版本号,一般只需要通过三位数字的版本号: 主版本号.次版本号.修订号

  • 主版本号 :做了一些不兼容的API修改,可以理解为一个大的产品更新。
  • 次版本号 :新增了一些功能,可以理解为合并了一个feature。
  • 修订号 :修复了一些bug,可以理解为合并了一个hotfix。

版本号(测试)

假如我们想要发布 1.0.1 版本,在开发团队内部,可能会提交多次的测试版本,交付给测试人员测试。这时候需要基于 1.0.1 版本号后面,加上一些其他的版本号。

  • alpha :内测版,一般不向外部发布,bug会比较多,功能也不全,一般只有测试人员使用。
  • beta :公测版,该版本仍然存在很多bug,但比alpha版本稳定一些。这个阶段版本还会不断增加新功能。
  • RC :发行候选版本,基本不再加入新的功能,主要修复bug。是最终发布成正式版的前一个版本,将bug修改完就可以发布成正式版了。
  • Release :正式发布版,官方推荐使用的版本。在正式发布的时候,可以不加Release,即 1.0.1 等同于 1.0.1-Release

可能基于这些版本号还有更细致的划分,这个可以根据实际项目情况调整。例如:v1.0.0-beta.1、v1.0.0-beta.2,或v1.0.0-200910-beta等。

微信扫一扫,分享到朋友圈

gitflow工作流

使用WSL2挂载Linux硬盘 在Windows上访问ext4等文件系统

上一篇

任天堂《塞尔达无双》新作曝光引发轰动!穿越到旷野之息百年前

下一篇

你也可能喜欢

gitflow工作流

长按储存图像,分享给朋友