create by db on 2021-1-25 16:34:46
Recently revised in 2021-1-25 19:34:56前端

闲时要有吃紧的心思，忙时要有清闲的趣味python

本文已参与好文召集令活动，点击查看：后端、大前端双赛道投稿，2万元奖池等你挑战webpack

目录git

前言github
正文web
总结npm

前言

返回目录编程

无规矩不成方圆，编程也同样。后端

若是你有一个项目，从始至终都是本身写，那么你想怎么写均可以，没有人能够干预你。但是若是在团队协做中，你们都张扬个性，那么代码将会是一团糟，好好的项目就被糟践了。不论是开发仍是往后维护，都将是灾难。

这时候，有人提出了何不统一标准，你们都按照这个标准来。因而 ESLint，JSHint 等代码工具如雨后春笋般涌现，成为了项目构建的必备良品。

Git Commit 规范可能并无那么夸张，但若是你在版本回退的时候看到一大段糟心的 Commit，恐怕会懊恼不已吧。因此，严格遵照规范，利人利己。

正文

返回目录

提交规范的做用

大多数状况下，看提交历史的人跟提交代码的人都不是同一我的，当别人阅读你的提交历史时，他极可能是不知道具体代码细节的，你如何在最短的时间内让他一眼知道每次提交的意义：

每次提交影响的具体范围？
这个 bug 在哪次提交中被修复了？
这个新功能是在哪次提交中增长的？
修改是否向下兼容？
是否回滚了代码？
是否只是修改了文档、调整了代码格式？
是否修改了测试、是否进行了重构？
是否对代码进行了性能优化？

提交规范的格式

用什么规范？

如今市面上比较流行的方案是约定式提交规范（Conventional Commits），它受到了 Angular 提交准则的启发，并在很大程度上以其为依据。

约定式提交规范是一种基于提交消息的轻量级约定。它提供了一组用于建立清晰的提交历史的简单规则；这使得编写基于规范的自动化工具变得更容易。这个约定与 SemVer 相吻合，在提交信息中描述新特性、bug 修复和破坏性变动。

它的 message 格式以下:

<type>[optional scope]: <description> // header
// 空一行
[optional <body>]
// 空一行
[optional <footer(s)>]

复制代码

举个简单的例子：

feat(config): 容许 config 对象直接从其余 config 继承

BREAKING CHANGE: 在 config 对象中增长 `extends` 字段，用于从其余继承 config

close issue #23
复制代码

固然咱们也能够写的简洁一些

feat: 容许 config 对象直接从其余 config 继承
复制代码

注：

在命令行里 git commit 时，若是你想进行多行 commit 编辑，能够经过 git commit -a 进入编辑界面；若是是单行，能够直接 git commit -m 'COMMIT MESSAGE' 完成提交。

格式讲解

一. header(必填)

header 部分只有一行，包括三个字段：type（必需）、scope（可选）和 description（必需）。

总的来讲，关键就是 header 这部分，至于<body>和<footer(s)>可省略

例如:

feat:新增财务报表
复制代码

1. type(必填)

type 为必填项，用于指定 commit 的类型，约定了 feat、fix 两个主要 type，以及 docs、style、build、refactor、revert 五个特殊 type，其他 type 暂不使用。（参考人人贷大前端技术中心）

# 主要type
feat:     增长新功能
fix:      修复bug

# 特殊type
docs:     只改动了文档相关的内容
style:    不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build:    构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert:   执行git revert打印的message

# 暂不使用type
test:     添加测试或者修改现有测试
perf:     提升性能的改动
ci:       与CI（持续集成服务）有关的改动
chore:    不修改src或者test的其他修改，例如构建过程或辅助工具的变更
复制代码

注：

当一次改动包括主要 type 与特殊 type 时，统一采用主要 type。

2. scope(选填)

可选项，用来讲明这次修改的影响范围，格式为项目名/模块名，能够是一个文件的地址，如 /lib/utils；也能够是某个功能点 parser，不建议超过两个单词

如：

.all       //表示影响面大 ，如修改了网络框架 会对真个程序产生影响
.loation   //表示影响小，某个小小的功能
.module    //表示会影响某个模块 如登陆模块、首页模块 、用户管理模块等等
复制代码

注：

若是一次 commit 修改多个模块，建议拆分红屡次 commit，以便更好追踪和维护。

3. description(必填)

必填项，是 commit 目的的简短描述，不超过 50 个字符。

规范以下：

以动词开头，使用第一人称如今时，好比 change，而不是 changed 或 changes
第一个字母小写
结尾不加句号（.）

二. body(选填)

可选项，具体的修改信息应该尽可能详细，通常不用写。

body 主要描述改动以前的状况及修改动机，对于小的修改不做要求，可是重大需求、更新等必须添加 body 来做说明。

三. footer(s)(选填)

可选项，放置备注啥的，若是是 bug ，能够把 bug id 放入，通常不用写。

commitizen

这个一款基于 Node 的交互式约束命令工具，适合喜欢使用命令行的小伙伴。

使用详情请参考 Git commit message 规范 | 掘金 - 人人贷大前端技术中心

git 设置模板

对于喜欢使用如sourceTree同样有着界面的git工具的同窗，就能够采用 git 配置模板的方式。

使用详情请参考老鸟都应该注意的git 提交规范| 博客园 - Four two

总结

返回目录

固然了，实际中，也不必定要采用这种规则，可是你能够借鉴它的，而后本身那边再根据实际状况变更。

提交规范在于之后维护方面是很是有利的，先不说远的，近的话，使用 Git 时，合并代码一般会有冲突，有些突发意外，好比另外的人不当心将你的代码覆盖了，并且这个功能已是好久以前的了，那怎么办呢？一般状况，本地有备份当然好，可是估计也没有那我的会将本身每次提交，都本地保存一份，由于那样显得效率低下和根据项目的周期和需求，项目愈来愈大，这样的话，本地备份的包也会愈来愈多。没有人会选择这种方式。最后的方式就是版本回退，固然了，前提是你提交信息必须简洁明了，否则的话像鬼知道是哪一个。

另外关于何时提交，尽量是完成一个新的功能或者是优化某个功能，解决某个 bug 等等就提交。可是这里有个前提就是，你本地必须测试没有问题，不然那样等于作无用工。

路漫漫其修远兮，与诸君共勉。

参考文献：

后记：Hello 小伙伴们，若是以为本文还不错，记得点个赞或者给个 star，大家的赞和 star 是我编写更多更丰富文章的动力！GitHub 地址

文档协议

db 的文档库由 db 采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
基于 github.com/danygitgit上的做品创做。
本许可协议受权以外的使用权限能够从 creativecommons.org/licenses/by… 处得到。

关于 Git 提交规范

前言

正文