Commit message 的作用
● 提供更多的历史信息,方便快速浏览
● 过滤某些commit(比如文档改动),便于快速查找信息
● 直接从commit生成Change log
● 可读性好,清晰,不必深入看代码即可了解当前commit的作用。
● 为 Code Reviewing(代码审查)做准备
● 方便跟踪工程历史
● 提高项目的整体质量,提高个人工程素质
Commit message 的格式
Commit message 包括三个部分:Header,Body 和 Footer
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
Header部分只有一行,包括三个字段:type(必需)、scope(可选)和subject(必需)
(1)type
type用于说明 commit 的类别,只允许使用下面的标识
feat:新增功能(feature)
fix:修补bug
docs:仅仅修改了文档,比如 README, CHANGELOG, CONTRIBUTE等等
style: 仅仅修改了空格、格式缩进、逗号等等,不改变代码逻辑
refactor:重构(即不是新增功能,也不是修改bug的代码变动)
test:增加测试,包括单元测试、集成测试等
chore:构建过程或辅助工具的变动
type:代表某次提交的类型,比如是修复一个bug还是增加一个新的feature。
perf: 优化相关,比如提升性能、体验
revert: 回滚到上一个版本
ci:自动化流程配置修改
注:如果type为feat和fix,则该 commit 将肯定出现在 Change log 之中
(2)scope
scope用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。
(3)subject
①subject是 commit 目的的简短描述,不超过50个字符。
②以动词开头,使用第一人称现在时,比如change,而不是changed或changes
③第一个字母小写
④结尾不加句号(.)
Body 部分是对本次 commit 的详细描述,可以分成多行
Footer 部分只用于两种情况:
(1)不兼容变动
如果当前代码与上一个版本不兼容,则 Footer 部分以BREAKING CHANGE开头,后面是对变动的描述、以及变动理由和迁移方法
BREAKING CHANGE: isolate scope bindings definition has changed.
To migrate the code follow the example below:
Before:
scope: {
myAttr: 'attribute',
}
After:
scope: {
myAttr: '@',
}
The removed `inject` wasn't generaly useful for directives so there should be no code using it.
(2)关闭 Issue
如果当前 commit 针对某个issue,那么可以在 Footer 部分关闭这个 issue
Closes #234
也可以一次关闭多个 issue
Closes #123, #245, #992
如果当前 commit 用于撤销以前的 commit,则必须以revert:开头,后面跟着被撤销 Commit 的 Header
revert: feat(pencil): add 'graphiteWidth' option
This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
①Body部分的格式是固定的,必须写成This reverts commit .,其中的hash是被撤销 commit 的 SHA 标识符。 ②如果当前 commit 与被撤销的 commit,在同一个发布(release)里面,那么它们都不会出现在 Change log 里面。如果两者在不同的发布,那么当前 commit,会出现在 Change log 的Reverts小标题下面。
commit message工具
Commitizen是一个格式化commit message的工具。
1.在cmd中通过npm来全局安装:
npm install -g commitizen
2.在项目目录下创建package.json文件
npm init
3.打开项目执行如下命令:
commitizen init cz-conventional-changelog --save --save-exact
注意:如果是第二次配置,需要用–force:
commitizen init cz-conventional-changelog --save --force
4.将未暂存文件所有变化提交到暂存区
git add .
① git add . :他会监控工作区的状态树,使用它会把工作时的所有变化提交到暂存区,包括文件内容修改(modified)以及新文件(new),但不包括被删除的文件。
②git add -u :他仅监控已经被add的文件(即tracked file),他会将被修改的文件提交到暂存区(git add --update的缩写)。add -u 不会提交新文件。
③git add -a :是上面两个功能的合集(git add --all的缩写)
5.命令行输入提交命令
git cz
输入命令后依次提示:
①上、下键选择要提交的更改类型
②此更改的范围是什么(例如组件或文件名)?(按回车键跳过)
③写一个简短的祈使句来描述这个变化
④提供更详细的更改说明:(按回车键跳过)
⑤有什么重大变化吗?
⑥这一变化是否会影响
任何未解决的问题?
6.再推送到本地git仓库
git push
注意:
① 代码需要提测,并且自己都测试OK了,如果一次性测试通过则可以把master合并到自己的分支,然后push自己的分支,进行提测
② 代码提测了,如果有问题,把问题修改好后,再push自己的分支
打印日志命令
git log
1.输出CHANGELOG记录,(文件名称自己设置),通过以下命令,在项目中生成 CHANGELOG.md 文件
①安装生成 Change log 的工具
$ npm install -g conventional-changelog-cli
② 通过提交记录生成 CHANGELOG.md
$ conventional-changelog -p -i CHANGELOG.md -s
2.打印出 git log 的日志记录(详细日志记录)
git log > 文件名
例如:git log >1.txt
在该项目路径中可查看 1.txt 日志记录文件
type类型可自行配置
type是可以自己配置和修改的,在项目路径下的
目前我们现在用的前后端分离模式属于第一阶段,下一阶段可以在前端工程化方面,对技术框架的选择、前端模块化重用方面,可多做考量。也就是要迎来“==前端为主的 MV* 时代==”。
当您必须使用匿名函数,请使用箭头函数表示法,它创建了一个在 this 上下文中执行的函数的版本,这通常是你想要的,而且这样的写法更为简洁。如果你有一个相当复杂的函数,你或许可以把逻辑部分转移到一个声明函数上。
standard是一个开源的JS代码规范库,制定了所谓standard(标准)的JS代码规范,配合编辑器插件可以实时检查代码规范以及语法错误,通过执行命令检查代码规范以及语法错误,自动修复(可以直接修复的)不合规范的代码,使其符合规范
对于一个多人团队来说,制定一个统一的规范是必要的,因为个性化的东西无法产生良好的聚合效果,规范化可以提高编码工作效率,使代码保持统一的风格,以便于代码整合和后期维护。
为了编写可维护的代码,我们把很多函数分组,分别放到不同的文件里,这样,每个文件包含的代码就相对较少,很多编程语言都采用这种组织代码的方式。在Node环境中,一个.js文件就称之为一个模块(module)
引号的使用,单引号优先(如果不是引号嵌套,不要使用双引号)、空格的使用问题:(关键字后 符号后 排版 函数 赋值符号= )等、不写没有使用过的变量,如果定义了一个变量,后来一直没有参与过运算,那么不应该定义这个变量...
嵌套的节点应该缩进;在属性上,使用双引号,不要使用单引号;属性名全小写,用中划线做分隔符;不要在自动闭合标签结尾处使用斜线(HTML5 规范 指出他们是可选的);不要忽略可选的关闭标签;
CommonJS规范规定,每个模块内部,module变量代表当前模块。这个变量是一个对象,它的exports属性(即module.exports)是对外的接口。加载某个模块,其实是加载该模块的module.exports属性。module.exports属性表示当前模块对外输出的接口
W3C通过设立领域(Domains)和标准计划(Activities)来组织W3C的标准活动,围绕每个标准计划,会设立相关的W3C工作组织(包括工作组、社区组、商务组等)。W3C会根据产业界的标准需求调整Domains和Activity的设置及相关的工作组设置。
不要使用 @import 与 <link> 标签相比,@import 指令要慢很多,不光增加了额外的请求次数,还会导致不可预料的问题。CSS有些属性是可以缩写的,比如padding,margin,font等等,这样精简代码同时又能提高用户的阅读体验。
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!