git commit你们一般都是怎么写的呢？
我通常用的比较多的是feat、modify、fix、chore这些。
feat一般是新增页面或者组件。
modify用的最多，只要是在原有文件做了修改，都算这个。
fix就是修复了一些bug或者问题，有的问题只是改个文案啥的。
chore一般就是改了脚手架插件配置等，写的比较简单，commit就叫优化配置文件啥的。
另外有时候改动非常小，比方说修改错别字、改个文案、删掉log、加一行注释之类的，这样的改动需要单独加一个commit么，有时候一个文件会来回这样改。
我之前试过git commit --amend --no-edit，这个相当于追加到上一个提交里面，只是有个副作用，那就是如果别人在这个中间有提交，拉取代码似乎会出现一个merge的记录。
说一说你们的开发习惯吧，有哪些好的经验可以分享一下呢。
中国的企业环境和互联网氛围本来就非常懒散，像你这种能考虑到提交规范的人少之又少，能强制要求禁止写修改、bugfix已经是有一些认知能力的团队了。像规范这种东西，就好像是劳动法里的建议，制定了，大家都不会遵守的，制定规则者自己都做不到。我建议你可以为自己的团队制定这样的规范，但是简单，方便，适合大家就好，不要过于严苛，不然随着领导一句：“着急要，赶紧改改发上去，代码检查，跳过就行了”从此刻就崩盘了。
目前行业里公认的Commit Message规范是Angular提交规范，如果你可以参与一些开源项目，你可以增强这方面自己的能力，不过现在衍生了 Conventional Commits specification. 很多开发工具基于此规范, 格式如下:
极客观点
项目管理
HarmonyOS
<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，查找来源，定位问题，非常清晰。
8 回答4.8k 阅读✓ 已解决
6 回答3.5k 阅读✓ 已解决
6 回答2.4k 阅读
5 回答6.4k 阅读✓ 已解决
3 回答2.5k 阅读✓ 已解决
3 回答2.2k 阅读✓ 已解决
3 回答2.6k 阅读✓ 已解决
个人觉得，没必要太过教条。
commit 记录的目的就是用来记录代码的变更历史的。尽量保证 commit 的首行能却确切的表明修改的内容就已经很不错了，至于要不要加 fix/typo/feat 这些，在我看来，毫无必要。
不过，如果你们的有项目管理系统的话，我倒是非常建议，你把对应的 Ticket ID 标识加到 commit 信息里面，这样在未来遇到这块代码的时候，也能找到原始需求来知道这里为什么要这样做。
举例：
对于这种情况，还是上面那样，如果能一局 commit 描述清楚，都可以。
出现 merge 是因为你使用的是 merge 进行合并，并且不满足 ff(快速合并)