git管理规范

转自：前端GIT规范 - 简书 (jianshu.com)

目前实际运行的规范：

1、每人开发新功能时， 从maste拉取最新代码创建自己的分支（如果开发多个功能，则创建多个分支，因为所有功能可能不一起上线）
2、功能开发完后，合并到develop分支进行测试
3、上线当天将自己分支合并到master ， 然后打包上线

 

前言

master 分支为主分支(保护分支)，不能直接在master分支上进行修改代码和提交；master分支为线上版本分支，代码只能从dev分支merge，且每次merge需要加上Tag 版本号。

主分支master

master分支永远受保护，master分支只接收merge操作，不可在master分支上开发，进行commit，push操作。
每次发布正式上线的稳定版本(发布后)，将当前发布版本merge到master分支。
master分支的代码永远和线上代码保持同步。

主开发分支dev

dev分支为主开发分支，是各功能分支的合并总分支，各功能分支统一merge到dev，可以进行commit，push，merge操作。
一般不在dev分支上进行新功能的开发；dev分支用来做不同分支的代码整合，
每次master发布后，需要把master的代码merge到dev，保持比master的代码更新。

功能性分支feature

feature分支为功能性分支，根据不同需求创建独立的功能分支，开发完成后merge到dev分支。
功能性分支feature用来进行新功能开发的分支，此分支由dev分支checkout出来，可以进行commit，push，merge操作。
按照功能或者版本可以同时checkout多个feature分支并行开发，开发完毕统一merge回dev。

测试分支release

测试分支release为bug修复分支，即测试分支。

热更新分支hotfix

hotfix分支为热更新分支，紧急修复master分支上的bug，修复完成后merge到master分支，然后删除。
hotfix分支是由master分支checkout出来，用于热修复线上bug用，可以进行commit，push，merge操作。
修复完毕经验证后直接发布，发布完成后merge到master分支。

Tag版本号

Tag 采用三段式，v版本.里程碑.序号，如：v1.2.1。
架构升级或架构重大调整，修改第1位
新功能上线或者模块大的调整，修改第2位
bug修复上线，修改第3位

commit 规范

init: 初始化
feat: 新特性
fix: 修改问题
refactor: 代码重构
docs: 文档修改
style: 代码格式修改, 注意不是 css 修改
test: 测试用例修改
build: 构建项目
chore: 其他修改, 比如依赖管理
scope: commit 影响的范围, 比如: route, component, utils, build…
subject: commit 的概述

例如:
git commit -m "fix: 修复xxbug"
git commit -m "feat: 开发xx功能"

作者：small_zeo
链接：https://www.jianshu.com/p/01bb99f3f03a
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。