gitflow笔记

by@sea

tag的意思是功能标签，是为了应对branch不能太多的问题。

今天给大家大致讲两点

一、分支类型定义

二、分支tag版本规范

一、分支类型定义，共5个

1、master，只读发布到生产分支

2、develop，只读开发的分支，是开发的基础分支

3、feature，功能分支，也就是真正需要在上面开发的分支，需要迭代的分支

4、release，测试分支，测试人员使用，基于develop，测试并修复bug后推送回develop

5、hotfix，线上bug修复分支，顾名思义热修复分支，紧急bug修复分支，主要是处理生产代码问题

GitFlow的常用分支

1、master，最终需要发布的分支

主分支 , 产品的功能全部实现后 , 最终在master分支对外发布

该分支为只读唯一分支 , 只能从其他分支(release/hotfix)合并 , 不能在此分支修改

另外所有在master分支的推送（合并）应该打标签做记录,方便追溯

例如release合并到master , 或hotfix合并到master

2、develop，与master同步，被开发所基于

主开发分支 , 基于master分支克隆

包含所有要发布到下一个release（测试分支）的代码

该分支为只读唯一分支 , 只能从其他分支合并

feature功能分支完成 , 合并到develop(不推送)

从develop拉取release分支 , 提测

release/hotfix 分支上线完毕 , 合并到develop并推送

3、feature，用于迭代，落实到每个开发者

功能开发分支 , 基于develop分支克隆 , 主要用于新需求新功能的开发

功能开发完毕后合到develop分支(未正式上线之前不推送到远程中央仓库（master仓库，以免线上环境源码污染）!!!)

feature分支可同时存在多个 , 用于团队中多个功能同时开发 , 属于临时分支 , 功能完成后可选删除

此分支的生命周期以合并到develop为结束，也就是当合并到develop以后，此分支就作废，不能再用了，如果此feature提交的bug并未修复，或者是没有开发完整，需要从develop克隆为release分支继续克隆。

4、release，测试分支，供测试人员使用，测试发现的bug在此分支修改完合并回develop分支

测试分支 , 基于feature分支合并到develop之后  , 从develop分支克隆

主要用于提交给测试人员进行功能测试 , 测试过程中发现的BUG在本分支进行修复 , 修复完成上线后合并到develop/master分支并推送(完成功能) , 打Tag

属于临时分支 , 功能上线后可选删除

此分支的生命周期以合并到develop为结束，也就是当合并到develop以后，此分支就作废，不能再用了，如果此

5、hotfix，紧急bug修复分支

补丁分支 , 基于master分支克隆 , 主要用于对线上的版本进行BUG修复

修复完毕后合并到develop或master分支并推送 , 打Tag

属于临时分支 , 补丁修复上线后可选删除

所有hotfix分支的修改会进入到下一个release

附：分支开发流程图

主要工作流程

1 . 初始化项目为gitflow , 默认创建master分支 , 然后从master拉取第一个develop分支

2 . 从develop拉取feature分支进行编码开发(多个开发人员拉取多个feature同时进行并行开发 , 互不影响)

3 . feature分支完成后 , 合并到develop(不推送 , feature功能完成还未提测 , 推送后会影响其他功能分支的开发)

    合并feature到develop , 可以选择删除当前feature , 也可以不删除 . 但当前feature就不可更改了 , 必须从release分支继续编码修改

4 . 从develop拉取release分支进行提测 , 提测过程中在release分支上修改BUG

5 . release分支上线后 , 合并release分支到develop/master并推送

     合并之后 , 可选删除当前release分支 , 若不删除 , 则当前release不可修改 . 线上有问题也必须从master拉取hotfix分支进行修改

6 . 上线之后若发现线上BUG , 从master拉取hotfix进行BUG修改

7 . hotfix通过测试上线后 , 合并hotfix分支到develop/master并推送

    合并之后 , 可选删除当前hostfix , 若不删除 , 则当前hotfix不可修改 , 若补丁未修复 , 需要从master拉取新的hotfix继续修改

8 . 当进行一个feature时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上

    即合并develop到当前feature分支

9 . 当进行一个release分支时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上

    即合并develop到当前release分支 (!!! 因为当前release分支通过测试后会发布到线上 , 如果不合并最新的develop分支 , 就会发生丢代码的情况)

二、tag功能版本命名规则（分支tag版本规范）

一直以来，Jenkins的任务ID成了是否作为粒度的问题，tag问题刚好能解决这个问题。

利用tag来搞清楚每次要提交的功能点，还有矛盾的地方就是，每次迭代需求，都应该以最后一次的提交为准，即使后面的错误覆盖了前面的正确，也应该查明原因，大不了根据版本号来恢复就是了。

这里列出版本号命名规则：

版本格式：主版本号.次版本号.修订号

版本号递增规则如下：

1. 主版本号：当你做了不兼容的 API 修改，

2. 次版本号：当你做了向下兼容的功能性新增，

3. 修订号：当你做了向下兼容的问题修正。

我们可以从开始

打tag的示例：

// 打标签git tag -a v1.0.0 -m "电站一期"// push 标签到远程仓库git push origin v1.0.0

注意：

一般的都是兼容的版本，所以，主版本会长期保持不变，除非是改版等原因，修订版本号主要是线上bug修复会递增

次版本号是主要的版本号，用于迭代。

实施过程：

主要是一些分支的命名，以及tag的版本问题，以及tag的注释问题

分支命名：

master

develop

这两个分支是唯一分支，不做修饰

feature，需要修饰，比如feature_plantstatistic (电站统计需求)，以需求为命名，禁止使用拼音。

分支命名规范

• master: master 分支就叫master 分支

• develop: develop 分支就叫develop 分支

• feature: feature 分支 咱们暂时可以按 feature_wechat_v2.0.1 这种命名规范来，后面有更好的命名规范咱们再改。v2.0.1 表示当前迭代的版本号，wechat 表示当前迭代的名称，这里我们是开发小程序迭代，就命名了 wechat

• release: release 分支的名称我们直接命名为这次需求的版本号，比如：2.0.1， 因为后面当我们使用gitFlow 工具时，当我们完成release 分支时，这个 release 分支名会直接 当做 在master 上的 tag名，这样我们就不需要再 在master 分支上打 tag了

• hotfix: hotfix 分支的命名我们暂时可以按 hotfix_v2.0.2 这种来进行命名，v2.0.2 表示这次修复的版本的版本号