Gitflow以及分支管理

Author Avatar
A Man Has No Name 8月 09, 2017
  • 在其它设备中阅读本文章

Git Flow使用介绍

流程图

  • feature(多个、玫红)。主要是自己玩了,差不多的时候要合并回develop去。从不与master交互
  • develop(1个、黄色)。主要是和feature以及release交互
  • release(同一时间1个、绿色)。总是基于develop,最后又合并回develop。当然对应的tag跑到master这边去了。生命周期很短,只是为了发布
  • hotfix(同一时间1个、红色)。总是基于master,并最后合并到master和develop。生命周期较短,用了修复bug或小粒度修改发布
  • master(1个蓝色)。没有什么东西,仅是一些关联的tag,因从不在master上开发

分支定义

master

此分支不允许直接修改,而且此分支上的代码,所有的代码,必须随时可以发布到线上。

Develop

同样,此分支代码不允许直接修改。同时这个分支,随时准备发布测试,release。

Feature

  1. 来源自develop分支,开发新功能都是在这个分支上。
  2. 坚决不建议两个人一起开发一个feature
  3. 开发完成,合并回develope分支。
  4. 命名: feature-*
  5. 此分支不需要保留

Release

  1. 此分支来自于develop分支, 准备测试,并且等待发布。
  2. 最终合并会develop和master
  3. 命名: release-*
  4. 注意,这个分支是给QA测试的分支, QA提出的bug要在这里进行修复。
  5. 发布到master的时候,需要按照版本号管理打tag。

注意, 一旦进行Release之后,非本次迭代的的功能Feature,不允许混合到这里。

Hotfix

  1. 来自于master分支
  2. 合并会master和develop分支
  3. 命名: hotfix-*

仅用于修复紧急的线上bug,并且注意打,正确的版本号tag。

软件版本管理

命名规则: 主版本号.子版本号.修正版本号 (beta, demo.. 选填简短描述)

  • 主版本号(master): 此版本号,除非重大重构,否则不需要更改。初始版本为0.
    比如,我们开发一个新项目,那么就是版本 v0.1.0; 如果我们开第二次大版本演进,底层进行了大变动,向后不再兼容,那么可以依次递增,比如 v1.1.0
  • 子版本号(release):迭代版本号, 比如本次开发的第二个迭代: v0.2.0 v1.2.0, 这次的修改,一定是向后兼容的
  • 修正版本号(hotfix): 修正bug的的v0.2.1, v1.2.2

  • 一旦release开发完成,合并到主分支上,如果本次开发,涉及到底层重构,一定要再大版本上加一;若果只是完成了一次迭代, 则只是在小版本更新加一。