这里说的版本管理，特指发布的版本管理。而不是指代码的版本管理。当然，代码的版本管理也是数据信息来源的一部分。
规范git commit提交记录，
开发人员随意的提交记录不利于回顾分析，因此需要有一定的标准，其中Anjular团队规范比较受大家欢迎，同时需要一定工具来支持，方便使用。
Angular 团队的 commit 规范
它的 message 格式如下:
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
分别对应 Commit message 的三个部分：Header，Body 和 Footer。
Header
Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
- type: 用于说明 commit 的类型。一般有以下几种:
feat: 新增feature
fix: 修复bug
docs: 仅仅修改了文档，如readme.md
style: 仅仅是对格式进行修改，如逗号、缩进、空格等。不改变代码逻辑。
refactor: 代码重构，没有新增功能或修复bug
perf: 优化相关，如提升性能、用户体验等。
test: 测试用例，包括单元测试、集成测试。
chore: 改变构建流程、或者增加依赖库、工具等。
revert: 版本回滚
- scope: 用于说明 commit 影响的范围，比如: views, component, utils, test...
- subject: commit 目的的简短描述
Body
对本次 commit 修改内容的具体描述, 可以分为多行。如下所示:
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
# initial commit
Footer
一些备注, 通常是 BREAKING CHANGE(当前代码与上一个版本不兼容) 或修复的 bug(关闭 Issue) 的链接。
可以利用一些工具来方便提交
安装nodejs
安装conEmu
conEmu主要是解决在windows中查看log中文乱码的问题，需在conEmu中设置环境变量
image.png
添加 set LANG=zh_CN.UTF-8
安装 commitizen
commitizen是一个帮助规范commit message的工具，它可以帮我们控制 commit 的格式，并让提交复杂格式时比git commit -m更加容易
# 需要同时安装commitizen和cz-conventional-changelog，后者是adapter
$ npm install -g commitizen cz-conventional-changelog
# 配置安装的adapter
$ echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
# 使用
$ git cz
对于windows系统，~目录对应C:\Users\xxx
我们可以根据项目定制提交的模板，在项目目录下建立文件.cz-config.js， 内容如下：
'use strict';
module.exports = {
types: [
{value: 'feat', name: '特性: 一个新的特性'},
{value: 'fix', name: '修复: 修复一个Bug'},
{value: 'docs', name: '文档: 变更的只有文档'},
{value: 'style', name: '格式: 空格, 分号等格式修复'},
{value: 'refactor', name: '重构: 代码重构，注意和特性、修复区分开'},
{value: 'perf', name: '性能: 提升性能'},
{value: 'test', name: '测试: 添加一个测试'},
{value: 'chore', name: '工具: 开发工具变动(构建、脚手架工具等)'},
{value: 'release', name: '发布: 发布版本'},
{value: 'revert', name: '回滚: 代码回退'}
],
scopes: [
{name: '模块1'},
{name: '模块2'},
{name: '模块3'},
{name: '模块4'}
],
// 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: '选择一种你的提交类型:',
scope: '选择一个scope (可选):',
// used if allowCustomScopes is true
customScope: 'Denote the SCOPE of this change:',
subject: '短说明:\n',
body: '长说明，使用"|"换行(可选)：\n',
breaking: '非兼容性说明 (可选):\n',
footer: '关联关闭的issue，例如：#31, #34(可选):\n',
confirmCommit: '确定提交说明?'
},
allowCustomScopes: true,
allowBreakingChanges: ['特性', '修复'],
// limit subject length
subjectLimit: 100
};
安装commitlint
有了commitizen可以帮助方便提交，但是无法强制，所以我们需要一个提交时检查的工具，commitlint可以帮我们达到此目的。
commitlint是一个提交验证工具。原理是可以在实际的 git commit 提交到远程仓库之前使用 git 钩子来验证信息。提交不符合规则的信息将会被阻止提交到远程仓库。
安装：
npm install -g @commitlint/cli @commitlint/config-conventional
为了可以在每次 commit 时执行 commitlint 来 检查我们输入的 message，我们还需要用到一个工具 —— husky。
husky 是一个增强的 git hook 工具。可以在 git hook 的各个阶段执行我们在 package.json 中配置好的 npm script。
npm install --save-dev husky
建立文件 package.json,指明hooks
{
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}
}
建立文件 commitlint.config.js 配置验证规则
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [
2,
'always',
[
'WIP', // 开发中
'feat', // 新特性
'improvement', // 加强现有特性
'fix', // 修补bug
'refactor', // 重构
'docs', // 文档
'test', // 单元测试
'config', // 配置文件
'style', // 格式需改
'perf', // 性能提升
'ci', // ci
'revert', // 版本回退
'release', // 发布版本
'chore', // 其他修改
],
],
'type-empty': [2, 'never'], // type不能为空
'type-case': [0, 'always', 'lower-case'], // type不限制大小写
'subject-empty': [2, 'never'], // subject（简短得描述）不能为空
'subject-max-length': [1, 'always', 50], // subject最大长度，超出只会警告，不阻止提交
'body-leading-blank': [1, 'always'],
'footer-leading-blank': [1, 'always'],
'header-max-length': [2, 'always', 72],
}
};
这样，提交的检查配置就完成了，提交时使用git cz命令即可
maven 生成CHANGELOG.md
使用插件git-changelog-maven-plugin，可以在构建时自动生成changelog,pom.xml中的配置如下:
<plugin>
<groupId>se.bjurr.gitchangelog</groupId>
<artifactId>git-changelog-maven-plugin</artifactId>
<version>1.62</version>
<executions>
<execution>
<id>GenerateGitChangelog</id>
<phase>generate-sources</phase>
<goals>
<goal>git-changelog</goal>
</goals>
<configuration>
<templateContent>
< {{title}} {{#hasIssueType}} *{{issueType}}* {{/hasIssueType}} {{#hasLabels}} {{#labels}} *{{.}}* {{/labels}} {{/hasLabels}}
{{/hasLink}}
{{^hasLink}}
### {{name}} {{issue}} {{title}} {{#hasIssueType}} *{{issueType}}* {{/hasIssueType}} {{#hasLabels}} {{#labels}} *{{.}}* {{/labels}} {{/hasLabels}}
{{/hasLink}}
{{/hasIssue}}
{{^hasIssue}}
### {{name}}
{{/hasIssue}}
{{#commits}}
**{{{messageTitle}}}**
{{#messageBodyItems}}
* {{.}}
{{/messageBodyItems}}
[{{hash}}](https://github.com/{{ownerName}}/{{repoName}}/commit/{{hash}}) {{authorName}} *{{commitTime}}*
{{/commits}}
{{/issues}}
{{/tags}}
]]>
</templateContent>
<file>CHANGELOG.md</file>
</configuration>
</execution>
</executions>
</plugin>
maven发布版本
使用插件maven-release-plugin，可以方便的管理版本发布流程，配置 pom.xml
配置 scm
<scm>
<!--release包需要放入的nexus或者其他maven release包的仓库url地址-->
<url>http://172.16.30.215:8082/repository/maven-releases/</url>
<!--connection, developerConnection: 都是连接字符串，其中后者是具有write权限的scm连接 -->
<!--需要打包项目的git地址-->
<developerConnection>scm:git:http://172.16.30.210/chenrm/commitizen-test.git</developerConnection>
<!--需要打包项目的git地址-->
<connection>scm:git:http://172.16.30.210/chenrm/commitizen-test.git</connection>
<tag>demo-1.0.4</tag>
</scm>
配置插件
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>3.0.0-M1</version>
<configuration>
<scmCommentPrefix>release</scmCommentPrefix>
<scmDevelopmentCommitComment>@{prefix}: prepare for next development iteration</scmDevelopmentCommitComment>
<scmReleaseCommitComment>@{prefix}: prepare release @{releaseLabel}</scmReleaseCommitComment>
<!--git用户名-->
<username>chenrm@witsoft.cn</username>
<!--git密码-->
<password>Abcd1234</password>
<!--mvn目标指令-->
<goals>-f pom.xml deploy</goals>
</configuration>
</plugin>
由于发布的过程会将jar发布到私有仓库，因此需将仓库地址定义在pom.xml中
<distributionManagement>
<snapshotRepository>
<id>maven-snapshots</id>
<name>User Porject Snapshot</name>
<url>http://172.16.30.215:8082/repository/maven-snapshots/</url>
<uniqueVersion>true</uniqueVersion>
</snapshotRepository>
<repository>
<id>maven-releases</id>
<name>User Porject Release</name>
<url>http://172.16.30.215:8082/repository/maven-releases/</url>
</repository>
</distributionManagement>
发布过程中会上传，需要NEXUS的用户名密码，这个在maven的settings.xml中配置
<server>
<id>maven-releases</id>
<username>admin</username>
<password>Abcd1234</password>
</server>
<server>
<id>maven-snapshots</id>
<username>admin</username>
<password>Abcd1234</password>
</server>
这样，在发布版本时，使用命令
mvn -DpreparationGoals=clean release:clean release:prepare
mvn -Darguments="-Dmaven.test.skip=true" release:perform
会打包当前版本，发布到NEXUS的release库，同时将pom.xml中版本号升级为下一版本号的SNAPSHOT版本
