因为 git 提交时的描述信息,需要在你的合作开发者之间共享,所以大多数情况下 git 提交信息并不只能被你一个人明白。于是就诞生了约定式提交这样的规范。 业内普遍认可的的约定式提交规范,为约定式提交 (Conventional Commits)。 约定式提交规范Conventional Commits是一种用于给提交信息增加人机可读含义的规范,是基于提...
https://www.conventionalcommits.org/zh-hans/v1.0.0-beta.4/#约定式提交规范 gitmoji https://gitmoji.js.org/ 学无止境,谦卑而行.
这时候一个 commit 加一个 revert 就是两个提交了。我们难道不能做好了再提交上去吗? 不能。原因有两个,一个是环境,你做好之后必须通过提交,才能发布到可以测试的环境;另一个是,功能往往是两个人合作(前端+后端模式),两个人要同步代码,此时至少需要一个人提交。
//校验提交配置:.commitlintrc.jsmodule.exports={extends:["@commitlint/config-conventional"],rules:{}};
约定式提交规范 以下内容来源于:https://www.conventionalcommits.org/zh-hans/v1.0.0-beta.4/ 每个提交都必须使用类型字段前缀,它由一个名词组成,诸如feat或fix,其后接一个可选的作用域字段,以及一个必要的冒号(英文半角)和空格。 当一个提交为应用或类库实现了新特性时,必须使用feat类型。
Git 每次提交代码时,都需要写 Commit Message (提交说明),否则就不允许提交。 $ git commit -m '第一次提交' 在工作中一份清晰简介规范的 Commit Message 能让后续代码审查、信息查找、版本回退都更加高效可靠。 Commit Message 的标准格式 Commit Message 标准格式包括三个部分:Header,Body,Footer ...
revert::撤销之前的提交。 merge::合并分支或解决冲突。 release::发布一个版本。 hotfix::发布紧急修补补丁。 build::构建过程或工具相关的更改。 ci::与持续集成(Continuous Integration)相关的更改。 config::配置文件的更改。 data::与数据相关的更改,如数据库操作、数据结构等。
在日常的开发工作中,我们通常使用 git 来管理代码,当我们对代码进行某项改动后,都可以通过 git commit 来对代码进行提交。 git 规定提交时必须要写提交信息,作为改动说明,保存在 commit 历史中,方便回溯。规范的 log 不仅有助于他人 review, 还可以有效的输出 CHANGELOG,甚至对于项目的研发质量都有很大的提升。
1. -m/–message:用于指定提交的说明信息。 “` git commit -m “commit message” “` 2. –allow-empty:允许提交一个空的提交。 “` git commit –allow-empty -m “empty commit” “` 3. -a/–all:自动将所有已经被 Git 管理的修改文件添加到暂存区,并进行提交。
–`-m ““`:指定提交信息; –`-a`:自动将所有已经被Git管理的文件提交到版本库中,省略了`git add`的步骤; –`-p`:交互式地选择要提交的变更内容。 五、其他注意事项 –commit命令只会将你已缓存的更改(通过`git add`添加到暂存区)提交到版本库中,如果某个文件没有添加到暂存区,那么它的修改不会被com...