Git分支GitFlow开发规范

图片[1]-Git分支GitFlow开发规范-码蜂屋

规范化管理代码库分支有助于版本库在演进过程中始终保持简洁,主干结构清晰。各个分支各司其职,有利于后续的维护更新,避免版本发布带来的混乱问题。

参阅资料

《A successful Git branching model》

《Git官方文档--Branching Workflows》

以下为Git分支开发规范的简单总结

分支结构

主要分支

master

  • 主分支,用于部署生产环境的分支,需确保master分支稳定性
  • master分支存储了正式发布的历史
  • 属于只读唯一分支,只能从其它分支(如develop,hotfix)合并,不能直接在此修改
  • 所有向master分支的Push推送都应当打TAG标签做记录,方便追溯

develop

  • 开发分支,基于master分支检出的平行分支
  • develop分支始终保持最新完成以及bug修复后的代码
  • 属于只读唯一分支,只能从master以外的分支(如feature,hotfix)合并,不能直接在此修改

下为master和develop平行分支示意图:

图片[2]-Git分支GitFlow开发规范-码蜂屋

支持分支

feature(官方亦称topic)

  • 功能分支,基于develop分支检出,用于新功能的开发
  • feature分支可同时存在多个,用于团队中多个功能同时开发
  • 命名规则: feature/*,如feature/shopping_cart,feature/user_login
  • 属于临时分支,最终会被合并回develop(作为新版本功能)或丢弃(放弃功能),最后可选删除
  • feature通常仅存在于开发人员存储库中(本地库),而不存在于远程origin

下为feature分支应用示意图:

图片[3]-Git分支GitFlow开发规范-码蜂屋

release

  • 发布分支,基于develop分支检出,用于准备发布新阶段版本
  • 用于Bug测试及修复,文档生成和其它面向发布任务
  • 属于临时分支,最终会先被合并到master(发布新版本),打TAG标签,再被合并到develop,最后可选删除
  • 命名规则:推荐为release-*release/*,如release-1.0

下为release分支应用示意图:

图片[4]-Git分支GitFlow开发规范-码蜂屋

hotfix

  • 补丁分支,基于master分支检出,用于对线上发布的版本进行BUG修复
  • 属于临时分支,最终会先被合并到master(发布新版本,亦称修复版本),打TAG标签,再被合并到develop,可选删除
  • 命名规则:推荐为hotfix-*hotfix/*,如hotfix-1.0.1

下为hotfix分支应用示意图:

图片[5]-Git分支GitFlow开发规范-码蜂屋

最后

推荐使用对Git Flow很好应用的图形工具SourceTree,可以帮助我们很好的理解和管理git分支。

下图为SourceTree工作流默认配置:

图片[6]-Git分支GitFlow开发规范-码蜂屋

© 版权声明
THE END
喜欢就支持以下吧
点赞7 分享
评论 共2条
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片
    • 头像137博客0