关于前端git提交规范的探讨？
git commit你们一般都是怎么写的呢？
我通常用的比较多的是feat、modify、fix、chore这些。
feat一般是新增页面或者组件。
modify用的最多，只要是在原有文件做了修改，都算这个。
fix就是修复了一些bug或者问题，有的问题只是改个文案啥的。
chore一般就是改了脚手架插件配置等，写的比较简单，commit就叫优化配置文件啥的。
另外有时候改动非常小，比方说修改错别字、改个文案、删掉log、加一行注释之类的，这样的改动需要单独加一个commit么，有时候一个文件会来回这样改。
我之前试过git commit --amend --no-edit，这个相当于追加到上一个提交里面，只是有个副作用，那就是如果别人在这个中间有提交，拉取代码似乎会出现一个merge的记录。
说一说你们的开发习惯吧，有哪些好的经验可以分享一下呢。
共有2个答案
中国的企业环境和互联网氛围本来就非常懒散，像你这种能考虑到提交规范的人少之又少，能强制要求禁止写修改、bugfix已经是有一些认知能力的团队了。像规范这种东西，就好像是劳动法里的建议，制定了，大家都不会遵守的，制定规则者自己都做不到。我建议你可以为自己的团队制定这样的规范，但是简单，方便，适合大家就好，不要过于严苛，不然随着领导一句：“着急要，赶紧改改发上去，代码检查，跳过就行了”从此刻就崩盘了。
目前行业里公认的Commit Message规范是Angular提交规范，如果你可以参与一些开源项目，你可以增强这方面自己的能力，不过现在衍生了 Conventional Commits specification. 很多开发工具基于此规范, 格式如下:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>git commit命令的编辑界面类似这个结构, 分为三个部分(每个部分使用空行分割):
标题行: 必填, 描述主要修改类型和内容
主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等
页脚注释: 放 Breaking Changes 或 Closed Issues
分别由如下部分构成:
type是commit的类型，有以下取值
feat: 新特性，新功能fix: 修改bugrefactor: 代码重构,较大调整docs: 文档注释相关修改style: 代码格式缩进等的修改test: 测试用例相关修改chore: 构建流程, 依赖定义，CI/CD文件修改等
scope是commit涉及范围一般是功能模块名subject是commit的概述, 建议符合50/72 formattingbody是commit具体修改内容, 分为多行, 建议符合50/72 formattingfooter是额外备注, 通常是 BREAKING CHANGE 或ISSUE的链接.
规范的commit message赏心悦目，尤其是后期遇到bug，查找来源，定位问题，非常清晰。
个人觉得，没必要太过教条。
commit 记录的目的就是用来记录代码的变更历史的。尽量保证 commit 的首行能却确切的表明修改的内容就已经很不错了，至于要不要加 fix/typo/feat 这些，在我看来，毫无必要。
不过，如果你们的有项目管理系统的话，我倒是非常建议，你把对应的 Ticket ID 标识加到 commit 信息里面，这样在未来遇到这块代码的时候，也能找到原始需求来知道这里为什么要这样做。
举例：
- Ticket#1234 修改用户名的正则验证规则
- Ticket#1234 重构了部分注册逻辑
- Ticket#1234 为部分方法添加了注释
有时候改动非常小，比方说修改错别字、改个文案、删掉log、加一行注释之类的，这样的改动需要单独加一个commit么，有时候一个文件会来回这样改。
对于这种情况，还是上面那样，如果能一局 commit 描述清楚，都可以。
出现 merge 是因为你使用的是 merge 进行合并，并且不满足 ff(快速合并)
-
一般来说，commit message 应该清晰明了，说明本次提交的目的。 目前，社区有多种 Commit message 的写法规范。下面介绍Angular 规范（见上图），这是目前使用最广的写法，比较合理和系统化，并且有配套的工具。 每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。 <type>(<scope>): <subject>// 空一
-
一般来说，commit message 应该清晰明了，说明本次提交的目的。 目前，社区有多种 Commit message 的写法规范。下面介绍Angular 规范（见上图），这是目前使用最广的写法，比较合理和系统化，并且有配套的工具。 每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。 <type>(<scope>): <subject>// 空一
-
说明 这是一套严格的团队开发规范，是 优帆远扬 团队内部 Laravel 工程师践行的开发规范。我们崇尚开放和透明的工程师文化，所以我们尽可能把信息公开。希望这些信息可以为他人参考和借鉴，发挥最大的价值。 目的 优帆远扬是一家崇尚远程协作的软件外包公司，工程师来自全球各地，规范化让我们的工程师训练有素，以此来提供更加高质量的软件交付。另一方面，我们也希望整个团队的项目经验能够得到继承，在每一次实战
-
受 Growth 3.0 开发的影响，最近更新文章的频率会有所降低。今天，让我们来谈谈一个好的 Git、SVN 提交信息是怎样规范出来的。 在团队协作中，使用版本管理工具 Git、SVN 几乎都是这个行业的标准。当我们提交代码的时候，需要编写提交信息（commit message）。 而提交信息的主要用途是：告诉这个项目的人，这次代码提交里做了些什么。如，我更新了 React Native Ele
-
前端规范 目的 旨在增强团队开发协作、提高代码质量和打造开发基石的编码规范，以下规范是团队基本约定的内容，必须严格遵循。 HTML 规范 基于 W3C 等官方文档，并结合团队业务和开发过程中总结的规范约定，让页面 HTML 代码更具语义性。 图片规范 了解各种图片格式特性，根据特性制定图片规范，包括但不限于图片的质量约定、图片引入方式、图片合并处理等，旨在从图片层面优化页面性能。 CSS 规范、命
-
此文档主要实现的目标：代码一致性和最佳实践。通过代码风格的一致性，降低维护代码的成本以及改善多人协作的效率。同时遵守最佳实践，确保页面性能得到最佳优化和高效的代码。
-
本文向大家介绍Git 提交后，包括了Git 提交后的使用技巧和注意事项，需要的朋友参考一下 示例 该挂钩在commit-msg挂钩之后立即被调用。它不能更改git commit操作的结果，因此主要用于通知目的。 该脚本不带任何参数，并且其退出状态不会以任何方式影响提交。
-
此手册主要实现的目标：代码一致性和最佳实践。通过代码风格的一致性，降低维护代码的成本以及改善多人协作的效率。同时遵守最佳实践，确保页面性能得到最佳优化和高效的代码。 此手册是在开发中积累下来的经验和参考其它规范/指南制定的，它只是起指导作用，除个别条目强制之外，大多数为非强制约束，开发者可根据自己的实际情况自行决定是否要遵守 该指南只是保证大方向一致性和最佳实践的阶段性总结，不是最后结论，它会随着