轻松上手,快乐学习!

Git 分支命名规范与工作流程


git分支命名规范与工作流程

快速预览

分支 命名 说明
主分支 master 主分支,所有提供给用户使用的正式版本,都在这个主分支上发布
预发布分支 release/v1.0.0 发布正式版本之前,最终确认的分支
开发主分支 develop/v1.0.0 开发主分支,永远是功能最新最全的分支
功能开发分支 feature/xxx 新功能分支,某个功能点正在开发阶段
紧急bugfix分支 hotfix/xxx 修复线上代码的 bug

详解

  • master:主分支,永远是可用的、稳定的、可直接发布的版本,不能直接在该分支上开发
  • release/v1.0.0 (bugfix):预发布分支,预发布分支是从 develop 分支上面分出来的。【预发布环境,该分支修复bug,稳定后合并进 develop 和 master 分支】
  • develop/v1.0.0:开发主分支,代码永远是最新,所有新功能以这个分支来创建自己的开发分支,该分支只做只合并操作,不能直接在该分支上开发。【测试环境,feature分支修复bug后,再合入】
  • feature/xxx (bugfix):功能开发分支,在 develop 上创建分支,以自己开发功能模块命名,开发完成或修复bug后合并到 develop 分支
  • hotfix/xxx:紧急bug修改分支,项目上线之后可以会遇到一些环境问题需要紧急修复,在对应版本的release 分支上创建,流程跟 release 分支相似,修复完成后合并 release 分支,根据情况判断需不需要再合并到 develop 和 master 分支

Workflow Diagram

Workflow Diagram

注意事项

  • 一个分支尽量开发一个功能模块,不要多个功能模块在一个分支上开发。
  • 开发过程中,如果组员A开发的功能依赖组员B正在开发的功能,可以待组员B开发好相关功能之后,组员A直接 pull 组员B的分支下来开发,不需要先将组员B的分支 merge 到 develop 分支。
  • feature 分支在申请合并之前,最好是先 pull 一下 develop 主分支下来,看一下有没有冲突,如果有就先解决冲突后再申请合并。

参考

  1. Git/GitHub branching standards & conventions
  2. Git 风格指南