type
status
date
slug
summary
tags
category
icon
password
一、Git 分支命名
- master：主分支，负责记录上线版本的迭代，该分支代码与线上代码是完全一致的。
- develop：开发分支，该分支记录相对稳定的版本，所有的feature分支和bugfix分支都从该分支创建。其它分支为短期分支，其完成功能开发之后需要删除
- feature/*：特性（功能）分支，用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 develop 分支，之后删除该分支。
- bugfix/*：bug修复分支，用于修复不紧急的bug，普通bug均需要创建bugfix分支开发，开发完成自测没问题后合并到 develop 分支后，删除该分支。
- release/*：发布分支，用于代码上线准备，该分支从develop分支创建，创建之后由测试同学发布到测试环境进行测试，测试过程中发现bug需要开发人员在该release分支上进行bug修复，所有bug修复完后，在上线之前，需要合并该release分支到master分支和develop分支。
- hotfix/*：紧急bug修复分支，该分支只有在紧急情况下使用，从master分支创建，用于紧急修复线上bug，修复完成后，需要合并该分支到master分支以便上线，同时需要再合并到develop分支。
二、工具链
安装依赖
使用husky+commlint 规范提交信息
配置文件
配置Git提交hook，在package.json下面加入以下配置
Commlint
commlint是一个commit 规范的检测工具，根据conventional commit format来定义的，主要参考主流开源库的提交规范。
三、Git Commit Message格式
Commit 开源库维护规范
Commitlint的规则
下面是提交内容格式示例，其中：
- type：对应上面的type说明
- optional scope： 文件修改的范围，可选填的，如：fix(src): fix login bug
- description：commit 描述信息
- body： 针对commit的详细描述，说明代码提交的详细说明，可选填的
- footer：是不兼容变更或关闭缺陷，则Footer必需，否则可以省略
Commit配置
在根目录下，新建
commitlint.config.js的文件。使用
standard-version 自动生成CHANGELOG如果是github开源项目，可以在仓库打上tag，并操作发布更新
github 项目创建新的release版本，把CHANGLOG.md内容拷贝过去即可。
参考链接
- 作者:HRope
- 链接:https://hrope.cn/article/git-commit-rule
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。