规范git commit提交记录和版本发布记录

在开发过程中我们一般都会用到git管理代码,在git commit提交代码时我们一般对git commit message随便写点简单的描述,可是随着项目参与人数的增多,发现提交的commit记录越来越杂乱,不便查阅,在网上找了下解决方案,总结一下方便在公司项目中运用。

commit message 格式

目前大家比较认可的是Angular团队的提交规范,很多工具也是基于此规范开发的。该提交规范格式如下:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

每一个commit message由header(必填)、body(选填)和footer(选填)组成,header部分包括三个字段:type(必填)、scope(选填)和?subject(必填)。为了方便浏览,每一行的commit message不应超过100个字符。

type
type 用于说明提交的commit的类别,有一下几种类型:

  • feat:添加新功能(feature)
  • fix:改bug
  • docs: 修改文档(documentation)
  • style: 只改样式(不影响代码运行的变动)
  • refactor:重构(即不是新增功能,也不是改bug的代码变动)
  • perf : 代码优化(提升代码性能)
  • test:增加测试
  • chore:构建过程或辅助工具的变动

scope
本次改动影响的范围
subject
对本次改动的简单描述
body
commit 具体修改内容的详细描述, 可以分为多行
footer
一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.

如何规范提交记录

上面介绍的是通用的git commit message规范,可是在git commit的时候如何用这写规范来写呢?

如果是个人项目我们可以为 git 设置 commit template, 每次 git commit 的时候在 vim 中自动带上模板信息, 自己只要按照模板信息填写就行

  1. 修改~/.gitconfig(.git/config文件), 添加:
[commit]
????template = .git_template
  1. 新建.git_template 内容可如下:
# head: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty (eg. if the change is a global or difficult to assign to a single component)
# - subject: start with verb (such as 'change'), 50-character line
#
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# footer:
# - Include a link to the ticket, if any.
# - BREAKING CHANGE
#

这样在项目中执行git commit时vim编辑会带上这些信息

如果我们的项目是多人参与的项目,这样就不合适了。这里我们推荐使用cz-customizable工具生成和约束commit message
cz-customizable有两种使用方式,这里我们采用官方推荐的第二种方式

  1. 安装cz-customizable
npm install  cz-customizable --save-dev
  1. 修改package.json文件,在scripts中加入commit命令
"scripts" : {
  ...
  "commit": "./node_modules/cz-customizable/standalone.js"
}
  1. 新建.cz-config.js文件
module.exports = {
types: [
    { value: 'feat', name: 'feat: A new feature' },
    { value: 'fix', name: 'fix: A bug fix' },
    { value: 'docs', name: 'docs: Documentation only changes' },
    {
        value: 'style',
        name: 'style: Changes that do not affect the meaning of the code\n (white-space, formatting, missing semi-colons, etc)',
    },
    {
        value: 'refactor',
        name: 'refactor: A code change that neither fixes a bug nor adds a feature',
    },
    {
        value: 'perf',
        name: 'perf: A code change that improves performance',
    },
    { value: 'test', name: 'test: Adding missing tests' },
    {
        value: 'chore',
        name:'chore: Changes to the build process or auxiliary tools\n and libraries such as documentation generation',
    }
],

scopes: [{ name: ''common }, { name: 'route' }, { name: 'components' }],
allowTicketNumber: false,
isTicketNumberRequired: false,
ticketNumberPrefix: 'TICKET-',
ticketNumberRegExp: '\\d{1,5}',
// it needs to match the value for field type. Eg.: 'fix'
/*
scopeOverrides: {
fix: [
{name: 'merge'},
{name: 'style'},
{name: 'e2eTest'},
{name: 'unitTest'}
]
},
*/
// override the messages, defaults are as follows
messages: {
    type: "Select the type of change that you're committing:",
    scope: '\nDenote the SCOPE of this change (optional):',
    // used if allowCustomScopes is true
    customScope: 'Denote the SCOPE of this change:',
    subject: 'Write a SHORT, IMPERATIVE tense description of the change:\n',
    body: 'Provide a LONGER description of the change (optional). Use "|" to break new line:\n',
    breaking: 'List any BREAKING CHANGES (optional):\n',
    footer: 'List any ISSUES CLOSED by this change (optional). E.g.: #31, #34:\n',
    confirmCommit: 'Are you sure you want to proceed with the commit above?',
},
allowCustomScopes: true,
allowBreakingChanges: ['feat', 'fix'],
// skip any questions you want
skipQuestions: ['body','breaking','footer'],
// limit subject length
subjectLimit: 100,
// breaklineChar: '|', // It is supported for fields body and footer.
// footerPrefix : 'ISSUES CLOSED:'
// askForBreakingChangeFirst : true, // default is false
};

该文件的配置信息可参考options

至此我们在提交代码时不在使用git commit命令,而是使用npm run commit这样就可以按照规范输出commit message。

校验commit message

上面的配置中我们并没有对commit message进行校验,也就是说如果项目中有成员继续使用git commit -m "message"提交仍是可以的,如果想增加commit message校验可以使用validate-commit-msg工具

  1. 安装相关依赖包
npm install validate-commit-msg  husky --save-dev 
  1. 在package.json文件中增加以下配置
"husky": {
    "hooks": {
        "commit-msg": "validate-commit-msg"
    }
}

这样我们团队中如果有成员使用git commit -m ‘message‘提交时,会提交不通过的提示

$ git commit -m 'aaa'
husky > commit-msg (node v8.11.3)
INVALID COMMIT MSG: does not match "<type>(<scope>): <subject>" !
aaa
husky > commit-msg hook failed (add --no-verify to bypass)

至此用cz-customizable规范git commit提交记录配置完成

记录版本发布

在之前的前端开发脚手架项目改动时,我们总是手动编写README文件,将做出的哪些改变一一列出来方便团队成员浏览知晓,后来在网上查阅参考别的项目得知我们可以通过
standard-version工具自动生成CHANGLOG文件记录版本变动

  1. 安装
npm install  standard-version --save-dev
  1. 修改package.json文件,在scripts中加入release命令
"scripts": {
    ...
    "release": "standard-version"
},

执行npm run release即可生成CHANGELOG文件,该文件中包含Features和Bug Fixes的提交记录

standard-version命令参数介绍

  --release-as, -r     Specify the release type manually (like npm version <major|minor|patch|1.1.0>) [字符串]
  // major: 1.0.0 -> 2.0.0, minor: 1.0.0 -> 1.1.0, patch : 1.0.0 -> 1.0.1
  --prerelease, -p     make a pre-release with optional option value to specify a tag id [字符串]
  --infile, -i         Read the CHANGELOG from this file                 [默认值: "CHANGELOG.md"]
  --message, -m        Commit message, replaces %s with new version [字符串] [默认值: "chore(release): %s"]
  --first-release, -f  Is this the first release?                          [布尔] [默认值: false]
  --sign, -s           Should the git commit and tag be signed?            [布尔] [默认值: false]
  --no-verify, -n      Bypass pre-commit or commit-msg git hooks during the commit phase [布尔] [默认值: false]
  --commit-all, -a     Commit all staged changes, not just files affected by standard-version [布尔] [默认值: false]
  --silent             Don't print logs and errors                         [布尔] [默认值: false]
  --tag-prefix, -t     Set a custom prefix for the git tag to be created   [字符串] [默认值: "v"]
  --scripts            Provide scripts to execute for lifecycle events (prebump, precommit, [默认值: {}]
  --skip               Map of steps in the release process that should be skipped    [默认值: {}]
  --dry-run            See the commands that running standard-version would run [布尔] [默认值: false]

// 第一次发布版本
npm run release -f
// 指定发布版本等级
npm run release -r minor

注意
使用standard-version生成CHANGELOG之前需要有完整的package.json文件,特别是有

"repository": {
    "type": "git",
    "url": "***"
}

否则生成的compare链接不完整,小编就犯过这个错

参考文章

  1. standard-version
  2. cz-customizable
  3. Husky
  4. 规范化 Git 版本提交信息和版本发布
  5. 优雅的提交你的 Git Commit Message

原文地址:https://www.cnblogs.com/jesse131/p/11529974.html

时间: 2024-11-02 21:29:13

规范git commit提交记录和版本发布记录的相关文章

Git Commit 提交规范

写好 Commit message 好处多多: 1.统一团队Git commit 日志风格 2.方便日后 Reviewing Code 3.帮助我们写好 Changelog 4.能很好的提升项目整体质量 业界比较推崇 Angular 的 commit 规范 http://suo.im/4rsYee Commit message 包括三个部分:Header,Body 和 Footer.完整格式如下: <type>(<scope>): <subject> <BLANK

windows和ubuntu下git commit提交后如何保存和退出,回到命令行

问题一: windows下git commit后会进入vim界面,不知道怎么操作 解决办法: 1.输入小写字母i,此时进入编辑模式,可以输入你想输入的内容 2.按下esc键,此时退出编辑模式,输入英文语法下的冒号:,再输入wq即可保存退出 3.也可以按下esc退出编辑模式之后连续按输入两个大写字母Z退出 问题二: Ubuntu下git commit后会进入类似vim界面,不知道怎么操作 解决办法: 1.Ubuntu下git commit后进入的是nano界面 2.输入需要内容后按下ctrl+x会

git commit命令

git commit 主要是将暂存区里的改动提交到本地的版本库.每次使用git commit 命令我们都会在本地版本库生成一个40位的哈希值,这个哈希值也叫commit-id. commit-id在版本回退的时候是非常有用的,它相当于一个快照,可以在未来的任何时候通过与git reset的组合命令回到这里. 1. git commit -m "message" -m 参数表示可以直接输入后面的message,如果不加 -m 参数,那么是不能直接输入message的,而是会调用一个编辑器

git commit

git commit git commit命令提交stage区的快照到项目历史中去(HEAD). 被提交的快照被认为是一个项目的安全版本. Git不会修改他们, 除非你显示的要求了. 和git add一样git commit是Git最重要的命令之一. 尽管名字相同git commit和svn commit完全不一样. 快照被提交到本地仓储,  不会和其他git仓储有任何的交互影响. 用法 git commit 提交stage区的快照. 上面的命令运行后会自动打开一个文本编辑器让你写一些关于这次c

commitizen和cz-customizable配置git commit message

起因 团队对提交的commit message格式有约定俗称的要求,但是没有一个统一的规范,导致大家提交的commit message或多或少不太一样.因此,需要一个工具来帮助大家统一commit message的格式,也方便后续的分析和拓展. commitizen commitizen 是一个帮助规范commit message的工具.安装后的效果如下图: 安装commitizen npm install -g commitizen 安装adapter commitizen根据不同的adapt

GIT入门笔记(20)- git 开发提交代码过程梳理

git开发提交流程新项目开发,可以直接往master上提交老项目维护,可以在分支上修改提交,多次add和commit之后,也可以用pull合并主干和本地master,解决冲突后再push 1.检出代码 git clone http://gitserver/kubernetes/api-gateway-controller.git git clone http://gitserver/kubernetes/api-gateway-engine.git 引入为eclipse工程,修改代码 2.提交代

Eclipse git commit错误;Committing changes has encountered a problem An Internal error occured

背景 在使用eclipse时,使用git commit 提交代码时,出项如下错误 解决方法 在工程目录下找到 .git 文件夹 ,找到里面的 index.lock 文件,然后删掉这个文件就可以了,如下图 原文地址:https://www.cnblogs.com/jixue/p/9581675.html

Git+Jenkins学习之路(八)之发布maven项目及按版本发布

一.什么是Maven maven是一个项目管理和综合工具.Maven提供给开发人员构建一个完整的生命周期框架. 开发团队可以自动完成该项目的基础设施建设,Maven使用标准的目录结构和默认构建生命周期 maven是属于Apache的开源项目 maven主要服务于java平台的构建.依赖管理.项目管理. 二.手动安装MAVEN (1)下载maven [[email protected]-node2 ~]# wget http://mirrors.hust.edu.cn/apache/maven/m

Git学习笔记2--创建版本库(仓库)、添加文件和提交

版本库可以简单的理解为一个目录,目录里面放需要被Git管理的东西,Git可以监控这个目录下文件的改动,并且可以在需要的时候还原到某一历史版本. 先找一个目录,可以创建了一个空文件夹: $ mkdir gitTest #注意,路径中最好不要有中文 $ cd gitTest/ 通过git init 可以将这个目录变为一个版本库: $ git init Initialized empty Git repository in c:/Users/starsli/Desktop/test/gitTest/.