前端工程化之commit规范（代码提交规范）

最新推荐文章于 2024-09-18 17:42:26 发布
最新推荐文章于 2024-09-18 17:42:26 发布
阅读量1w 收藏 28
点赞数 3
分类专栏： 前端 工程化 commit规范 文章标签： 前端 工程化 commit规范 前端工程化 husky
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/fesfsefgs/article/details/109435185
版权

其实commit规范不管是前端还是后端也好，我觉得吧，在任何的工程化的项目中都是不可或缺的部分啦，commit 提交不规范，项目维护和管理起来是极其麻烦的，毕竟每个人都具有自己的个性，commit message的格式也是参差不齐

git 可以帮我们很好地管理代码，但是在多人合作的时候，经常会碰到各种随意的 commit message，当你需要会看 commit message 的时候，就会很头疼。
幸运的是我们可以使用工具去处理掉这个问题，不让这种小问题影响到项目的进展

首先来看一下被业界广泛认可的 Angular commit message规范。

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

一个 commit message 由三部分构成：

标题行: 必填, 描述主要修改类型和内容
主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等
页脚注释: 放 Breaking Changes 或 Closed Issues
在这三部分中，<>中的内容分别表示：

type: commit 的类型

  • feat: 新特性
  • fix: 修改问题
  • refactor: 代码重构
  • docs: 文档修改
  • style: 代码格式修改, 注意不是 css 修改
  • test: 测试用例修改
  • chore: 其他修改, 比如构建流程, 依赖管理.
  • pref: 性能提升的修改
  • build: 对项目构建或者依赖的改动
  • ci: CI 的修改
  • revert: revert 前一个 commit

scope: commit 影响的范围, 比如: route, component, utils, build…
subject: commit 的概述, 建议符合 50/72 formatting
body: commit 具体修改内容, 可以分为多行, 建议符合 50/72 formatting
footer: 一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.

这时候我们需要工具像 lint 检查一样来帮我们约束 commit message 的书写。

最低0.47元/天 解锁文章
codingWeb
关注
专栏目录
Git Commit提交规范总结
拾年一剑 的专栏
02-27 6445
团队协作中，规范的Git提交记录，使提交历史明确可追溯，有助于更好的协作，方便后期代码的开发和维护
前端工程化之代码规范---ESLint + Prettier + husky + lint-staged代码规范全家桶
codingWeb的博客
11-07 1380
每个开发者都有自己的习惯，代码的风格也不尽相同，比如缩进的格数，结尾加不加分号,定义函数有没有空格，这些看似好像不起眼的风格，但在多人开发的时候，代码commit提交，可能就会出现一大片冲突，或者过多修改过的情况，对项目管理和维护是极其不友好的，而且在review，阅读项目代码的时候，一个项目中出现几种，甚至10几种的代码风格，我相信没人受得了这事，人都有一种惯性思维，习惯看一种风格，切换到其他风格可能需要适应一下，更别说人手一套风格的项目了，这肯定是不能接受的 ，这个问题很严重，必须得解决 ...
Commit提交规范
qq_43203586的博客
09-26 2006
Commit提交规范 整体上根据 angular 规范提交 commit，细微处做了修改。 <type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer> （1）type 提交 commit 的类型，包括以下几种 feat: 新功能 fix: 修复问题 docs: 修改文档 style: 修改代码格式，不影响代码逻辑 refact
前端代码规范- Commit 提交规范
最新发布
2401_86113453的博客
09-18 1633
约定式提交（Conventional Commits）是一种用于代码版本控制的规范，旨在通过明确和标准化提交信息来提高代码协作质量和效率。其基本原则是通过规定提交信息的结构和语义来提高代码版本控制的可读性、可维护性和自动化程度。约定式提交规范通常要求提交信息包括一个描述性的"类型"、一个可选的"作用域"、一个用于简洁说明的"主题"，以及可选的"正文"和"尾部"等组成部分。
git commit提交规范
axzzy的博客
11-03 2528
📈 (上升趋势图) :chart_with_upwards_trend : 添加分析或跟踪代码。🏁 (旗帜) :checkered_flag : 修复 Windows 下的问题。🌐 (地球) :globe_with_meridians : 国际化与本地化。✅ (白色复选框) :white_check_mark : 增加测试。💚 (绿心) :green_heart : 修复 CI 构建问题。🐧 (企鹅) :penguin : 修复 Linux 下的问题。🔒 (锁) :lock : 修复安全问题。
commit 提交规范
guxin_duyin的博客
05-17 181
<type>(<scope>): <subject> eg: feat(login): sso 接入； eg: feat(task-center/menu-details/ui): 任务详情layout； eg: feat(task-center/menu-details/logic): 任务详情logic； * type: >feat：新功能（feature）; >fix：修补bug; >docs：文档（docum.
commit 规范
qq_44482764的博客
04-28 504
基本格式： 每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。 <type>(<scope>): <subject> // 空一行 <body> // 空一行 <footer> Header 是必需的，Body 和 Footer 可以省略。 1. Header Header部分应只包含一行...
前端工程化之规范化标准
gongye2019的博客
04-20 460
规范化标准 在前端快速发展的今天，如果不能时刻保持学习就会很快被淘汰。分享一下前端工程化中有关于规范化标准的相关知识。每天进步一点点。 一、规范化概述 规范化是我们践行前端工程化中重要的一部分。 1、为什么要有规范化标准 软件开发需要多人协同 不同开发者具有不同的编码习惯和喜好 不同的喜好增加项目维护成本 每个项目或者团队需要明确统一的标准 2、哪里需要规范化标准 代码、文档、甚至是提交日志 开发过程中人为编写的成果物 代码标准化规范最为重要 3、实施规范化的方法 编码前人为的标准约定 通过工具实现 Lin
前端工程化-husky+commitizen+ 自定义cz-customizable适配器 git 提交代码规范化
Chameleon_zhao的博客
07-07 4538
1、使用husky添加git hooks（基于husky新版6.0.0进行git hooks） 1、npm install -D husky 2、创建.husky/目录并指定该目录为git hooks所在的目录 3、在package.json中添加prepare脚本 4、执行npm run prepare，本地会创建.husky目录 5、添加git hooks 创建一条 pre-commit hook npx husky add .husky/pre-commit "npm run test" 会在.
前端工程化之——代码规范五部曲
DUDUfine的专栏
05-25 1103
文章目录一、EditorConfig二、ESLint.eslintrc.eslintignore三、Prettier.prettierrc四、StyleLint五、hushy+Lint-staged+Commitlint知识拓展代码风格标准 Airbnb 和 Standard 一、EditorConfig 编辑器配置 EditorConfig是帮助跨各种编辑器和ide处理同一项目的多个开发人员维护一致的编码风格,文件中的设置会优先于用户/工作区设置，在开发过程中，可以通过对编辑器配置编码规则在开发过程就对代
git commit规范提交
酒无忧的博客
11-06 1190
Git每次提交代码时，都要写Commit Message（提交说明），通常情况下，Commit Message应该清晰明了，说明本次提交的目的和具体操作等。例如，有些人会写此次代码的修改是基于哪个模块，有些人会写解决了哪些Bug，有些则只写修改了哪个文件，中英文混用等等五花八门的Commit格式，这导致后续的代码维护成本很高，有时候提交人看Commit Message都不知道自己改了什么。比如查阅某个业务的修改历史，查阅某个时间段修复了哪些Bug，因为Commit没有统一的格式，就比较难快速获取这些信息。
commit规范
w96098的博客
03-17 539
每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。 Header部分只有一行，包括三个字段：type 、空格、和subject 。 1）type type用于说明 commit 的类别，如： * feat: 新功能 * fix: 修改bug * docs: 修改文档 * style: 格式化代码结构（不影响代码运行的变动) * perf: 性能优化 * refactor: 重构（即不是新增功能，也不是修改bug的代码变动，比如重命名变量） * chore
2023 年了，还有前端人不知道 commit 规范 ？
程序员成长指北
04-04 175
大厂技术高级前端Node进阶点击上方程序员成长指北，关注公众号 回复1，加入高级Node交流群一个开发人员需要知道的 commit 规范什么是约定式提交约定式提交（Conventional Commits）是一种用于代码版本控制的规范，旨在通过明确和标准化提交信息来提高代码协作质量和效率。其基本原则是通过规定提交信息的结构和语义来提高代码版本控制的可读性、可维护性和自动化程度。约定式提交...
前端工程化中的代码规范和commit规范
Zhuang_Allen的博客
04-26 426
前端工程化中的代码规范和commit规范 当我们编写代码的时候，由于任务时间紧，任务量重，需求不明确等等，会导致每个人的代码可能五花八门，潇洒不羁，可是当团队协作或者同事交接的过程中就会出现灾难性的，过多的争论和多余的解释，最后难免走上重构的道路。因此我们需要统一风格，不仅可以减少出 bug 的几率，而且能增加代码的可读性。 代码规范 对前端而言，通常我们会使用ESLint+Prettier来统一...
Git Commit 提交规范
江江的博客
07-05 298
Conventional Commits 规范是一种轻量级的提交信息约定。它提供了一套简单的规则，用于创建明确的提交历史，从而更容易在此基础上编写自动化工具。该规范与 SemVer（语义化版本）相辅相成，通过在提交信息中描述特性、修复和重大变更，明确版本变更的类型。
代码工程必备能力—Commit 规范
benjaminparker的博客
10-24 6167
Git是目前应用最为广泛的开源分布式版本控制系统，不论是对企业团队还是科研任务都需要掌握使用Git的技巧，文章重点在于总结如何使用Git的一些功能，包括讲述的文章、资源和个人的想法。 Git 官方网址：Git 一. Git Commit 的作用（干啥用的） Git Commit：指的是提交说明，用于标注此次修改的内容以及需要提示的信息,官方给出的解释是：Record changes to the repository（记录添加到仓库当中的修改）。 提供一个场景来做...
git 提交中的commit 规范
weixin_46761843的博客
08-06 3544
最近又接受一个项目，上面的eslint各种规范真的是稍不注意就会出问题。也是在网上找了很多，感觉下面的总结很好的解决了我的困境。记录一下。方便下次查看。 一、为什么需要规范？ 无规矩不成方圆，编程也一样。 如果你有一个项目，从始至终都是自己写，那么你想怎么写都可以，没有人可以干预你。可是如果在团队协作中，大家都张扬个性，那么代码将会是一团糟，好好的项目就被糟践了。不管是开发还是日后维护，都将是灾难。 这时候，有人提出了何不统一标准，大家都按照这个标准来。于是 ESLint，JSHint 等代码工.
项目的Commit 规范
吴小迪的博客
04-28 552
根据 angular 规范提交 commit，这样 history 看起来更加清晰，还可以自动生成 changelog。 <type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer> （1）type 提交 commit 的类型，包括以下几种 feat: 新功能 fix: 修复问题 docs: 修改文档 style: 修改代码格式，不影响代码逻辑 r
git提交commit规范
09-29
Git提交commit规范可以帮助我们在提交代码时更加规范、清晰地记录每次提交的目的和内容。常见的git提交commit规范有以下几种： 1. 使用约定的提交消息格式：一般使用"[类型]: 提交说明"的格式，其中类型可以是feat（新功能）、fix（修复bug）、docs（文档修改）、style（代码格式修改）、refactor（代码重构）、test（测试代码修改）等。 例如：feat: 添加用户注册功能 2. 提交消息的内容要简明扼要，清晰明了，用一句话描述本次提交的目的和内容。 3. 可以在提交消息中添加关联的issue编号，方便跟踪和查看。 4. 提交消息的第一行要尽量控制在50个字符以内，更详细的说明可以在第一行后面进行补充。 5. 可以使用一些常用的提交类型和动词，如feat（添加）、fix（修复）、docs（文档）、style（代码样式）、refactor（重构）、test（测试）、chore（构建/工具/其他）等。 请注意，git提交commit规范可以根据团队的实际情况和需求进行调整和扩展，重要的是保持一致性和清晰性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

codingWeb

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值