前端代码提交规范(git cz)

本文介绍了如何使用commitizen工具来规范前端项目的Git提交信息,以提高代码回溯和日志阅读的效率。通过安装和配置commitizen,开发者可以在提交时遵循统一的模板,包括feat、fix、docs等类型,使提交信息更清晰、有条理。

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

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

简介
所以就找到了一款适合大众而且也是相当知名的代码提交规范:commitizen(git cz),这款工具也是最早 Angular 团队提交代码的时候用的一套规范,在现今 github 和团队场景中运用十分广泛的工具。

说明
commitizen 也可以简写为:git cz 格式化工具,为我们提供规范了代码的提交信息,在团队中使用能统一提交信息,在往后的代码回溯或者日志生成能够快速的查找到对应的目录。

安装
npm 安装 commitizen

npm install commitizen

yarn 安装 commitizen

yarn add commitizen

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

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

1639147267659_C6D3C0ED-57BC-4b40-8E2A-7ACE3AA2B2A1.png

添加完 在控制面板中输入 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。是不是看上去很清晰!

好了,今天这一篇就是介绍 前端工程化的一些 规范工具,有什么问题欢迎随时留言~

### 关于周立功CAN通信Qt上位机实现教程 #### 环境配置 对于成功搭建基于Qt的CAN通信上位机应用程序,环境的选择至关重要。推荐使用较为稳定的版本组合来减少兼容性和稳定性方面的问题。具体来说,建议采用QT5.14.2搭配MinGW 32位编译器进行开发[^3]。 #### 添加CAN驱动支持 要使Qt能够处理CAN消息收发操作,则需引入相应的库文件以扩展其功能。这通常涉及到安装特定硬件厂商提供的SDK或是利用开源项目如SocketCAN接口来进行适配。确保所选方案适用于目标平台并遵循官方文档指导完成集成过程。 #### 创建图形界面 借助Qt Designer可以快速构建直观易用的操作面板,其中包括但不限于设置波特率、过滤条件等功能控件;同时预留显示区域用于呈现接收到的数据帧信息。通过信号槽机制连接UI组件事件与后台逻辑处理函数,从而实现实时交互效果[^1]。 #### 编写核心业务代码 以下是简化版的核心部分伪代码示例: ```cpp #include <QCanBus> #include <QCanBusDevice> // 初始化CAN设备实例 QCanBusDevice *canDevice; QString canInterfaceName = "socketcan_can0"; // 根据实际情况调整此参数值 void setupCanConnection() { QCanBus *bus = QCanBus::instance(); qDebug() << "Available plugins:" << bus->plugins(); if (!bus->isPluginAvailable("socketcan")) { qFatal("Cannot find the socketcan plugin"); } canDevice = QCanBus::createDevice("socketcan", canInterfaceName, this); connect(canDevice, &QCanBusDevice::framesReceived, this, [](){ const auto frames = canDevice->readAllFrames(); foreach (const QCanBusFrame &frame, frames) { processFrame(frame); // 自定义的消息解析方法 } }); } void sendCanMessage(const QByteArray& data) { QCanBusFrame frame(QCanBusFrame:: setFrameId(0x123)); frame.setPayload(data); bool success = canDevice->writeFrame(frame); } ``` 上述片段展示了如何创建一个简单的发送接收框架,在实际应用中还需要考虑错误恢复策略以及更复杂的协议细节等问题[^2]。 #### 测试验证 最后一步是对整个系统的功能性进行全面测试,确认各项指标均达到预期标准之后再投入使用。可以通过模拟不同场景下的输入输出情况来检验软件的表现是否稳定可靠,并据此优化性能瓶颈之处。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值