git flow 开发流程快速指南

如果需要开发一个新的功能 按照以下流程:

  1. 使用git flow创建一个feature。feature开发完成后在,使用git rebase develop命令将develop分支和当前分支并到一条线上面。之后要在git lab上面创建一个merge request做code review。
  2. review 通过后,manager通过“git checkout develop && git merge feature/[featureName] —no-diff” 合并到主开发分支上面。
  3. 使用git flow 创建一个release,这个release分支将作为测试发布分支。在测试环境发现bug需要修复,直接在这个release分支上面修改。
  4. 测试没有任何问题后,需要在git lab上面创建一个merge request 做code review 。
  5. review 通过之后,完成这个release分支,此时会创建一个tag。通过这个tag打包上线。

PS:上线分支都都要通过tag上线以便监控上线版本。develop分支上面不能直接提交代码。

如果在线上遇到bug,按照这样流程:

  1. 使用git flow创建一个hotFix,分支名称以当前线上分支版本加上一个四位版本号。如当前线上分支是1.8.3.4,你需要创建一个1.8.3.5分支。
  2. bug修复完成后,在这个分支上面直接打包发布测试环境,测试有问题直接在这个分支上面开发。
  3. 上线前需要提交code review。在git lab上面创建一个merge request 合并分支为master。通过后完成这个hot fix 分支开发。

以上是总结出来的具体操作流程。

解释为什么要在feature 分支要rebase 和 合并的时候要使用merge —no-ff

如果直接合并过去是这样的,如图:

使用rebase 和merge —no-ff的情况,如图

可以很明显的看出来使用了rebase和merge —no-ff 的这种方式让feature的显示更加直观。

关于系统版本的控制,具体的理论和完整的实践参照文档: http://semver.org/lang/zh-CN/

格式是x.y.z.h:

  • x为主版本,项目发布前都是0,正式上线后会变成1 ,之后一致保持,只有完全重构升级的时候才会变动。
  • y为此版本号,只有当有里程碑发布的时候向上升一位。
  • z为修订号,每次feature上线都会自动向上升一位
  • h为hotFix 修补版本号。比如线上版本位tag 1.4.8 ,遇到一个bug,新建hotFix的时候需要创建一个1.4.8.1的版本。如果此时没有新feature上线,又发现一个很急的问题,需要创建新的hotFix 版本为1.4.8.2。

PS:版本进位没有十进制的也没有进位的说法,比如之前的版本号是1.9.9 ,新的版本号是1.9.10。

尤鹏飞

继续阅读此作者的更多文章