告别混乱！一份精炼Git使用规范（分支、提交与命名）

为什么我们需要Git规范？

在多人协作的软件开发中，Git 是我们最得力的工具。然而，如果没有一套统一的Git使用规范，我们的代码库很快就会变得混乱不堪：分支命名五花八门、Commit信息含糊不清、代码历史难以追溯……这不仅降低了团队开发效率，也为项目埋下了质量隐患。

制定一套简洁明了的Git工作流和规范，不是为了增加束缚，而是为了让协作更顺畅，让代码库更健康。

**一、 分支规范 **

我推荐一种简化版的 Git Flow 模型，它足够清晰，能满足绝大多数项目的需求。

主要分支

• main (或 master): 主分支。存放随时可以发布到生产环境的、最稳定的代码。该分支应被保护，只接受来自其他分支的合并请求（Merge Request），不允许直接提交。
• develop: 开发分支。所有新功能的集成和测试都在这个分支上进行。可以把它看作是“下一个版本”的集散地。

临时分支

所有开发工作都应在临时分支上进行，它们有明确的生命周期，完成使命后即被删除。

• feature/... : 功能分支。用于开发新功能，是数量最多、最常用的分支。
• fix/... : 修复分支。用于修复在develop分支上发现的常规Bug。
• hotfix/... : 热修复分支。当生产环境出现紧急问题时，从main分支创建，修复后直接合并回main和develop。

二、 分支命名规范

清晰的Git分支命名能让我们在众多分支中快速识别其用途。

• 命名公式： [类型]/[简短描述或JIRA编号]

• 示例：

  • 开发用户登录功能： feature/user-login-module
  • 修复一个支付Bug： fix/payment-bug-TICKET-123
  • 紧急修复线上问题： hotfix/fix-gateway-timeout

**三、 代码提交规范 **

一次高质量的提交，包含两部分：高质量的代码和高质量的Commit Message。

1. 提交前：保证代码质量

提交一个格式完美的Commit，但代码本身却一团糟，是毫无意义的。在执行git commit之前，请确保：

• 代码在本地已经通过了所有测试。
• 代码符合团队的编码规范。
• 代码中的命名清晰、表意准确。

[作者推荐]

“好的命名”是高质量代码的灵魂。但在开发时，为了一个变量名而苦思冥想，常常会打断思路。为了解决这个痛点，我开发了一款基于AI的变量命名工具，帮助大家轻松获得规范、表意的命名。

• 在线地址： www.icanshock.fun/

• IDEA插件： 打开插件市场(Marketplace)，搜索 “Easy Naming” 即可找到。

提交前用它检查和优化一下命名，能显著提升代码的可读性。

2. Commit Message 规范

我们推荐使用 Conventional Commits 规范，它格式清晰，并且便于后续自动生成更新日志（Changelog）。

• 基本格式： <type>(<scope>): <subject>

• 常用 type 类型：

  • feat: 新功能 (feature)
  • fix: 修补bug
  • docs: 文档 (documentation)
  • style: 格式 (不影响代码运行的变动)
  • refactor: 重构 (既不是新增功能，也不是修改bug的代码变动)
  • test: 增加测试
  • chore: 构建过程或辅助工具的变动

• 示例：

  • feat(login): 新增手机短信登录功能
  • fix(api): 修复用户信息编辑错误问题
  • docs(readme): 更新安装文档

四、 合并请求 (Merge/Pull Request) 规范

• 当一个feature或fix分支开发完成后，应向develop分支发起合并请求（Pull Request）。
• 合并请求必须经过至少一位同事的代码审查（Code Review） 并批准后，方可合并。
• 合并成功后，应删除已被合并的临时分支，保持代码库的整洁。

结语

纪律带来自由。一套良好、统一的Git使用规范是高效、高质量团队开发的基石。希望这份精炼的指南能为你的团队带来帮助。

你所在的团队还有哪些值得分享的Git实践技巧呢？欢迎在评论区留言交流！