为什么需要Git规范？¶
在没有规范的团队协作中，Git版本控制常常会变成“一团乱麻”：有人随便创建分支，有人提交信息写得含糊不清，代码合并时各种冲突，想找一个历史版本修复bug却要翻遍所有提交记录……结果就是效率低下，协作混乱。
而统一的Git规范，就像团队协作的“交通规则”，能让每个人的操作清晰可预测，减少沟通成本，方便代码追踪和问题定位。接下来，我们就从最基础的“分支命名”和“提交信息”入手，一步步建立团队协作的Git规范。
一、分支命名规范：给每个分支“贴标签”¶
分支是Git的核心功能，规范分支命名能让所有人快速知道：这个分支是做什么的？从哪里来？要到哪里去？
1. 常见分支类型（团队协作中必备）¶
- 主分支（Master/Main）：项目的“源头”，保持绝对稳定，只接受合并，不直接在上面写代码。通常对应生产环境，一旦发布就不再修改。
- 开发分支（Develop）：集成开发中的功能，所有功能完成后会合并到这里，用于测试和预发布。
- 功能分支（Feature）：为新功能或大需求创建的分支，从Develop分支分出，完成后合并回Develop。
- 修复分支（Bugfix）：修复开发中发现的bug，从Develop分支分出，修复后合并回Develop。
- 热修复分支（Hotfix）：生产环境紧急bug的修复，从Master分支分出，修复后同时合并到Master和Develop。
2. 命名格式（团队必须统一）¶
- Feature分支：
feature/[需求ID]-[功能简述]
例：feature/123-user-login-form（需求ID123，功能是用户登录表单） - Bugfix分支：
bugfix/[bugID]-[bug简述]
例：bugfix/456-fix-login-validation（bugID456，修复登录验证问题） - Hotfix分支：
hotfix/[bugID]-[问题简述]
例：hotfix/789-fix-payment-crash（修复生产支付崩溃问题） - 主分支和开发分支：通常固定名称（Master/Main、Develop），不需要额外命名规则。
小技巧：¶
- 分支名称尽量简洁，但要包含关键信息（如需求ID/问题ID），方便用工具（如GitLab/GitHub）搜索。
- 避免中文和特殊符号（如
#、$），防止不同系统识别问题。
二、提交信息规范：让每次“提交”都有意义¶
提交信息是代码的“说明书”，好的提交信息能帮你（和队友）快速定位：这次改了什么？为什么改？
1. 为什么要规范提交信息？¶
- 避免“一堆乱改”：别人（或未来的你）看提交记录时，能一眼知道某次修改的目的。
- 方便版本管理：用工具（如Git log）筛选特定类型的提交（比如只看“fix”相关的）。
- 自动化工具支持：符合规范的提交信息能被自动生成变更日志（如Changelog）。
2. 最常用的“约定式提交”规范¶
格式：类型: 简短主题（不超过50字）[可选：详细描述]
类型（必选）：¶
- feat：新功能（比如添加用户注册、首页轮播）
- fix：修复bug（比如“用户登录后闪退”“按钮点击没反应”）
- docs：文档更新（比如README、API注释修改）
- style：代码格式调整（如缩进、空格，不影响逻辑）
- refactor：代码重构（比如优化函数逻辑，但不新增功能/修bug）
- perf：性能优化（如减少加载时间、提升查询速度）
- test：测试相关（比如新增单元测试、修复测试用例）
- chore：日常任务（如依赖更新、版本号修改、清理临时文件）
示例：¶
- ✅ 规范写法：
feat: add user registration form
（新功能：添加用户注册表单） - ✅ 规范写法：
fix: resolve login button unresponsive issue
（修复：解决登录按钮无响应问题） - ✅ 带详细描述：
docs: update API documentation
（详细：更新用户手册中“获取token”的步骤） - ❌ 不规范写法：
改了点东西（别人完全看不懂）
3. 如何记住规范？¶
- 类型首字母小写：
fix而非Fix（养成习惯更统一）。 - 主题简洁明了：用祈使句（如“add”而非“added”）。
- 描述换行：详细描述用空行隔开，写在主题下面，方便阅读。
三、规范落地：常用Git命令辅助操作¶
1. 创建分支（按规范）¶
# 先确保开发分支是最新的
git checkout develop
git pull origin develop
# 创建功能分支（示例：需求ID123，功能“用户登录表单”）
git checkout -b feature/123-user-login-form
2. 提交代码（按规范）¶
# 查看已修改文件
git status
# 添加所有修改（或指定文件）
git add . # 添加所有新增/修改文件
# 提交（示例：添加用户登录表单）
git commit -m "feat: add user registration form"
# 推送分支到远程
git push origin feature/123-user-login-form
3. 合并到开发分支（协作时）¶
# 切换到develop分支并拉取最新代码
git checkout develop
git pull origin develop
# 合并功能分支
git merge feature/123-user-login-form
# （可选）删除已合并的分支
git branch -d feature/123-user-login-form
4. 处理冲突（规范落地关键点）¶
如果合并时出现冲突，不要慌！按以下步骤解决：
1. 拉取最新代码：确保本地develop分支是最新的。
2. 手动修改冲突文件：打开冲突文件（Git会标记冲突区域，如<<<<<<< HEAD）。
3. 协商解决：和相关队友沟通，确定最终代码逻辑。
4. 标记冲突已解决：
git add . # 所有冲突文件解决后执行
git commit -m "merge: resolve conflicts in login form"
四、如何让团队严格遵守规范？¶
- 代码审查时强调：合并前检查分支命名和提交信息是否合规。
- 使用工具辅助：
- 用pre-commit钩子自动检查提交信息（比如要求必须包含feat/fix）。
- 在GitHub/GitLab的PR模板中明确规范要求。 - 形成团队共识：新人入职时讲解规范，定期回顾（比如每周10分钟）。
总结¶
Git规范的核心是“清晰可追踪”：分支命名让协作目标明确，提交信息让修改目的透明。刚开始可能觉得麻烦，但养成习惯后，代码会变得像“有索引的账本”——任何问题都能快速定位到源头，团队协作效率自然提升。
从今天开始，试试用规范的分支命名和提交信息写第一行代码吧！