git commit 不仅仅是保存代码，更是项目开发中沟通、记录和追溯问题的关键环节。核心在于编写清晰明了的 commit message，遵循特定格式（类型、范围、主题、正文、脚注），确保信息简洁、准确、易于理解。高级用法包括重新排序 commit（rebase）和合并 commit（squash），可优化 commit 历史的清晰度。
Git Commit：不止是保存代码那么简单
很多新手觉得 Git commit 就是把代码保存一下，这想法太天真了！它其实是项目开发中沟通、记录、甚至追溯问题的关键环节，用好了能让你事半功倍，用不好嘛……你懂的，debug 的噩梦。 这篇文章，我会带你深入了解 Git commit 的精髓，不止是“如何用”，更是“如何用好”。
先说说基础：你得知道 commit 是啥
简单来说，commit 就是你对代码库的一次快照。 每次修改代码后，用 commit 记录下这些修改，以及你做了什么，为什么这么做。这就像写日记一样，只不过日记记录的是你今天吃了啥，commit 记录的是你改了哪些代码，以及这些修改的目的。 别小看这“日记”，它能帮你找回之前的代码版本，也能方便团队协作，追溯问题的根源。 理解这一点非常重要，因为这直接决定了你写 commit message 的态度。
Git commit 的核心：commit message
写好 commit message 是 Git commit 的精髓所在。 一个糟糕的 commit message，就像一本没有目录的书，让人抓狂。 一个好的 commit message 应该简洁明了，清晰地描述你这次 commit 的内容。 我个人比较喜欢遵循这样的格式：
<type>(<scope>): <subject> <body> <footer>
：例如 feat (新功能)、fix (bug 修复)、docs (文档修改)、refactor (代码重构)、test (测试用例修改) 等。 这能让你一眼看出这次 commit 的类型。 ：可选，指明修改的范围，例如 auth (认证模块)、ui (用户界面) 等。 这能让你更方便地查找相关的 commit。 ：简短的描述，通常不超过 50 个字符。 用动词开头，清晰地说明做了什么。 - ：详细描述修改的内容，以及原因。 可以多写几行，解释清楚你的思路。
举个例子：
feat(auth): Implement JWT authentication This commit implements JWT (JSON Web Token) authentication for user login. It uses the `jsonwebtoken` library for token generation and verification. Closes #123
看到没？ 一目了然！
一些坑和建议
- 别写太长的 commit message: 没人喜欢读长篇大论。 如果修改的内容很多，可以拆分成多个小的 commit。
- 别用含糊不清的描述: 例如“修复了一些 bug”，“修改了一些代码”。 这简直就是灾难！
- 保持一致性: 坚持使用统一的 commit message 格式，方便阅读和查找。
- 利用工具: 一些 ide 或者 Git 客户端提供了 commit message 的辅助工具，可以帮助你写出更好的 commit message。
高级用法：rebase 和 squash
熟练掌握 Git rebase 和 squash 可以让你更好地整理你的 commit 历史，让你的 commit 历史看起来更清晰、更易于理解。 rebase 可以让你重新排序 commit，而 squash 可以让你将多个 commit 合并成一个。 但是，请谨慎使用 rebase，特别是当你已经将你的代码 push 到远程仓库后。
总结：Commit，不仅仅是代码的保存
Git commit 是一个强大的工具，它不仅仅是保存代码，更是项目开发中沟通、记录和追溯问题的关键环节。 通过学习和实践，掌握 Git commit 的技巧，能让你在团队协作中游刃有余，避免很多不必要的麻烦。 记住，写好 commit message，是程序员的基本素养！
