前端git提交规范(git cz)

本文介绍如何通过Commitizen工具规范代码提交说明,创建清晰的提交历史,提升代码管理效率。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

序:

最近在提交代码的时候发现每次提交的代码说明都是层次不齐的,看上去让人感觉到特别的凌乱。第一:让人看上去感觉这个程序猿好像不是“正规”出身,再一让自己在回溯代码的时候没有任何头绪。

安装 commitizen

npm install commitizen
yarn add commitizen

配置命令

等待安装完之后在对应的项目下的 package.json 文件夹下 添加如下命令:

"config": {
  "commitizen": {
    "path": "./node_modules/cz-conventional-changelog"
  }
}

在这里插入图片描述
添加完 在控制面板中输入 git cz 命令就会出现对应的 commitizen 提交规范步骤 如下:

git cz
? Select the type of change that you're committing: (Use arrow keys)
❯ feat:     A new feature 
  fix:      A bug fix 
  docs:     Documentation only changes 
  style:    Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) 
  refactor: A code change that neither fixes a bug nor adds a feature 
  perf:     A code change that improves performance 
  test:     Adding missing tests or correcting existing tests 

feat: A new feature
壮举:新功能

fix: A bug fix
修复:错误修复

docs: Documentation only changes
docs:仅文档更改

style: Changes that do not affect the meaning of the
样式:不影响代码含义的更改(空格、格式、缺少分号等


refactor: A code change that neither fixes a bug nor
重构:既不修复错误也不添加功能的代码更改


perf: A code change that improves performance
perf:提高性能的代码更改


test: Adding missing tests or correcting existing tests
测试:添加缺失的测试或纠正现有的测试

build: Changes that affect the build system or external dependencies
build:影响构建系统或外部依赖项的更改

ci: Changes to our CI configuration files and scripts
ci:对我们的 CI 配置文件和脚本的更改

chore: Other changes that dont modify src or test
杂项:不修改 src 或测试文件的其他更改

revert: Reverts a previous commit
还原:还原以前的提交

如果你修改了bug,那么第一步就是选择 fix选项:fix

第二步会出现一个 Specify a scope:意思就是这次修改的文件夹是那部分,我一般选择 src/home/banner…等等,这些文件夹可以选择更改的目录

第三步会出现write a short description:意思是写一段简短的描述。我一般会:修改了…bug等

其余选项可以直接敲回车就可,最后生成的commitizen 信息就是:fix(src/home/banner): 修改了…bug。是不是看上去很清晰!

### Git 前端 Commit 提交信息规范标准 在软件开发过程中,良好的提交信息有助于团队成员理解每次更改的目的和范围。对于前端项目而言,遵循统一的 `Git` 提交信息规范尤为重要。以下是关于 `Git` 前端提交信息的具体规范说明: #### 1. 结构化提交信息 提交信息通常由三部分组成:`Header`, `Body` 和 `Footer`[^4]。 - **Header**: 这一部分是最关键的部分,它包含了提交类型的描述以及简短的主题摘要。 - `<type>`: 表示本次提交的主要目的,常见的类型有 `feat`(新功能), `fix`(修复错误), `docs`(文档更新), `style`(代码格式调整), `refactor`(重构代码), `test`(测试相关改动) 等[^3]。 - `[<scope>]`: 可选字段,用于指定修改影响到的功能模块或组件名称。 - `<subject>`: 描述当前提交的核心内容,建议控制长度不超过50个字符,并保持简洁明了[^2]。 - **Body**: 如果需要进一步解释此次提交的原因或者实现细节,则可以在第二行留空之后继续书写详细的描述文字。这部分没有严格的字数限制,但应尽量清晰易懂。 - **Footer**: 主要用来记录 Breaking Changes 或者关联 Issue 编号等内容。如果有破坏性的改变发生,在此注明;如果解决了某个特定的问题也可以在此处提及对应的 issue id (e.g., Closes #12)[^2]. #### 2. 使用工具辅助生成标准化提交消息 为了简化手动编写复杂而精确的消息过程并减少人为失误的可能性,推荐使用像 `Commitizen`这样的工具来帮助创建符合惯例的标准提交信息。通过安装配置好后可以直接运行 `cz` 而不是普通的 git commit 来启动交互式的向导界面完成整个流程[^1]。 另外还可以配合 husky 设置 pre-commit hook 自动校验即将推送出去的新版本是否满足预定义好的规则集要求(比如 @commitlint/cli),从而强制执行这些最佳实践措施保障长期维护质量稳定可靠。 ```bash npm install --save-dev commitizen cz-conventional-changelog npx commitizen init cz-conventional-changelog --save-dev --save-exact ``` 以上命令会初始化一个基于 conventional changelog 的 commitizen 工作流环境设置完毕以后就可以利用 npx cz 替代传统的 git commit 方法来进行日常操作啦! ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值