git commit是将变更提交到本地缓存中而存在的，同时在commit时需要附上描述信息，说明本次提交是做了哪些变更，以便在今后追踪代码时，通过描述信息就能让读者知道哪些地方变化了。
这是一把双刃剑。用好了，能够保持项目提交记录清晰，起到追踪信息的作用；反之，则会带来更多的困扰。
下面我们就来看看应该如何用好git commit。
好的Commit的特点
提交的变更要单一且聚焦
一次好的commit应该是原子性的 - 即有且仅有一个逻辑的改变。请不要把多个相互独立的变更一次性提交。
例如：好的提交：只增加了用户验证就是一个单一的功能改变。
git commit -m "Add user authentication"
不好的提交：既增加了用户验证，同时又更新了UI样式
git commit -m "Add user authentication and update UI styles"
明确的描述信息
一个具体的描述能够清晰的解释该次commit做了什么，并且做了什么改动。在用户不用阅读代码的情况下，就能清晰的知道本次提交做了哪些改变。
好的提交：在用户登录功能中，修复了空指针导致的异常
git commit -m "Fix Correct null pointer exception in user login"
坏的提交：修复了一个bug。
git commit -m "Fix bug"
遵循统一的提交风格
遵守统一的提交风格，以保证在读commit的时候格式统一、一致，以提高易读性。一般遵循如下格式：
提交的类型+简短的描述
提交的类型一般包括：
- feat：新功能
- fix：修复bug
- chore：杂项
- refactor：代码重构
- style：代码风格变动
- test：测试代码变动
- build：构建代码变动
例如：在auth模块中增加了基于JWT的验证的新功能。
git commit -m "feat(auth): add JWT-based authentication"
在login模块中，修复了竞态条件的问题。
git commit -m "fix(login)：resolve race condition in login flow"
上面括号中的auth和login说明本次提交所作用的功能范围。
经过测试和验证的代码
确保提交的代码是经过测试和验证过的代码。提交未测试的代码会影响整个代码流程以及其他团队成员。
不好的Commit的特点
一次提交有大量变更且不聚焦
一次提交包含大量的修改是不好的commit。这会导致难以理解本次commit到底修改了什么。一次提交过多的修改，会对代码review和调试造成困难。
例如：以下是对整个项目做了修改并一起提交了
git commit -m "Update project"
提交的描述模糊不清
提交的描述说明模糊或对本次更改描述不清。这种描述信息缺乏细节且容易造成混乱，同时，也使追踪历史变化变的更困难。
例如：以下没有说明具体的变更是什么。
git commit -m "Stuff"
一次提交中有不相关的变更
将无关的更改合并到一个提交中，难以区分特定的更改，还会引入错误并使review过程变的复杂。
例如：以下把readme的修改和login模块的修改混合在了一起
git commit -m "Update readme and fix login issue"
不完整或没有经过测试的代码
提交不完整或未经测试的代码可能会让工作流程混乱，给其他团队成员带来困扰。
缺少上下文
在提交的说明中，缺少必要的上下文信息，难以理解为什么要做出这次变更。
总结
良好的commit对于在Git中保持干净和可理解的项目记录非常重要。通过遵循最佳实践，如保持提交的单一性、编写描述性消息、确保是经过测试的代码等，好的commit可以改善团队协作，使项目具有高度的可维护性。
原文地址：https://dev.to/sheraz4194/good-commit-vs-bad-commit-best-practices-for-git-1plc?ref=dailydev
