Git分支规范

【前言】

目前入职新公司一个多月，上级让我带领前端小组，其实入职没多久就发觉前端代码质量很差，提升代码质量一直都是个艰难而持续的过程，从git规范，到代码质量规范缺一不可，那么先从git规范开始。

 

 

【分支概要】

 

分支名称	分支说明
master	生产分支，不能直接在此分支开发
feature	功能分支，基于master分支创建的迭代分支
release	测试分支，feature分支开发完成，合并到这个分支
hotfix	修复分支，基于master分支创建

 

 

【基本规则】

master分支

不能直接开发，只能其他分支合并进来，不能将其合并至其他分支

命名规则：固定master

合并规则：

1. 迭代开发：git merge feat-xxx
2. 修复线上：git merge fix-xxx

注意：master只能合并feature、hotfix分支

其他规则：

1. 每一次合并完成后，需要打tag，方便回滚
2. tag命名规则：tag-feat-xxx_mmdd或tag-fix-xxx_mmdd，mmdd为当前月、日，例如tag-feat-order_1111

 

feature分支

每一次的迭代需求产生的临时分支，待开发完成、测试完成并发布上线后，删除

命名规则：feat-xxx，例如feat-order

创建规则：git checkout -b feat-xxx origin master

 

注意：开发完成后需合并至release分支

 

 

release分支

每一次的feature分支合并到此分支，不能将release合并至其他分支，用来部署开发、测试环境。

命名规则：固定release

合并规则：

1. 迭代开发：git merge feat-xxx
2. 修复线上：git merge fix-xxx

注意：release只能合并feature、hotfix分支

 

hotfix分支

修复线上bug，修复完成需合并到release、master分支

命名规则：fix-xxx，例如fix-order

创建规则：git checkout -b fix-xxx origin master

 

 

 

【其他规范】

commit提交信息，遵循：<type> explain 规范

type参照表

 

type	说明
feat	功能
fix	修复某个bug
docs	文档或注释
style	样式相关
refactor	重构
test	测试数据、模拟数据
other	其他

 

举几个栗子：

feat 多集配中心接口联调

fix 下拉回显修复

style 弹窗样式修改

refactor 导出逻辑重构