在团队开发中，规范的 Git 使用不仅是效率的体现，更是工程师素养的一部分。今天这篇文章，我们来聊一聊 Git 的最佳实践和 Commit 规范，帮你彻底告别“提交信息写啥好”的烦恼。
一、为什么我们需要「规范」？
先来看一段真实的 commit log：
<TEXT>
a1b2c3d fix
4e5f6g7 refactor
7g8h9i0 test
如果你是新来的开发者，看到这些信息，心里大概会 OS： “这都 fix 了什么？重构了啥？哪个 test 没过？”
规范的提交信息 = 可读性 = 可维护性 = 减少扯皮，这谁都知道。但问题就是：怎么写才算规范？
二、Commit 信息怎么写？推荐 Conventional Commits 规范
目前主流社区里，Conventional Commits（约定式提交）是最被广泛接受的方案。格式如下：
<TEXT>
<type>[optional scope]: <description>
[optional body]
[optional footer]
✅ 常用 type 类型说明：
| 类型（type） | 说明 | 示例 |
|---|---|---|
feat | 新功能 | feat: 支持夜间模式 |
fix | 修复问题 | fix: 修复登录页崩溃问题 |
refactor | 重构代码（非 Bug 修复） | refactor: 拆分 utils 模块 |
perf | 性能优化 | perf: 优化首页加载速度 |
test | 添加测试 | test: 添加用户登录单元测试 |
docs | 文档修改 | docs: 更新 README 使用说明 |
style | 格式化代码（无逻辑变动） | style: 统一缩进为 2 空格 |
chore | 杂项事务（如更新依赖） | chore: 升级 vite 到 v5 |
✅ 示例提交：
<TEXT>
feat(auth): 微信小程序一键登录
- 使用 wx.login 获取 code
- 后端换取 openid 并注册新用户
- 前端缓存 token 并跳转首页
三、团队协作中的 Git 分支策略建议
推荐一套简单的 Git Flow 工作流（适合小型团队）：
| 分支名 | 用途 | 说明 |
|---|---|---|
main | 主分支（永远可部署） | 禁止直接 push，只能合并 |
dev | 日常开发分支 | 团队成员基于此开发 |
feature/* | 功能分支 | 命名如 feature/login |
hotfix/* | 紧急修复主线 Bug | 命名如 hotfix/fix-login-crash |
✅ Pull Request = 做人的门槛
合并前必须 Code Review，别放臭虫进主线。
四、工具推荐：用好了省心十倍
-
Commitizen（交互式写 commit）：
<BASH> npm install commitizen -g cz -
Commitlint + Husky（强制规范）：
提交前自动校验 commit 格式，防止乱写。 -
git graph 插件（VS Code 的 Git Graph）：
图形化查看分支历史，一目了然。
五、总结一句话
Git 不是 Solo 工具，而是团队协作的核心基础设施。
写规范的 commit ≠ 浪费时间，是在节省未来的 Debug 时间。
欢迎留言交流，你们在团队里 Git 是怎么用的？有没有踩过类似的坑？评论区一起吐槽！
