Git分支与Commit常见提交规范

Git是目前最流行的版本控制系统之一, 它通过强大的分支管理能力, 极大地提高了软件开发的效率和灵活性. 如何有效地使用Git分支, 并建立一套清晰,规范的Commit提交信息, 以维护项目代码的可读性和可维护性.

Git分支策略

主分支(Main Branch)

• master/main: 代表生产环境的稳定代码。这个分支应该是永远可用的，只接受快照式的合并（merge）或变基（rebase），直接提交到此分支应尽量避免。
  开发分支（Development Branch）
• develop：日常开发分支，所有新功能的开发都应该在这个分支上进行，定期或在功能开发完成后，将其合并到主分支。
  功能分支（Feature Branch）
• feature：为每一个新功能创建一个分支，如feature/login-page。这有助于并行开发，保持主分支的干净，并方便代码审查。
  修复分支（Bug Fix Branch）
• hotfix或bugfix：当需要紧急修复生产环境的问题时使用，如hotfix/login-page或bugfix/login-page，修复完成后，应立即合并到master/main和develop分支。
  发布分支（Release Branch）
• release：当准备发布新版本时构建，从develop分支分出，用于最后阶段的测试，文档更新等。最终合并到master/main分支并打上标签（tag）。

分支命名规范

• 使用有意义的名称，如功能名，修复类型等，并遵循统一的前缀，如feature/，bugfix/，release/。

Commit提交规范

• 提交信息结构

<类型>(<范围>): <主题>
<空行>
<详细描述>

类型	描述
feat	新增xxx功能
fix	修复xxxBug
docs	变更xxx文档
refeactor	重构
test	测试xxx
chore	维护xxx
style	变更xxx代码格式或注释

• 类型：表示提交的类型，如feat（新功能），fix（修复），docs（文档），refactor（重构），test（测试），chore（维护），style（变更xxx代码格式或注释）
• 范围：可选，指明受影响的模块或组件
• 主题：简洁描述本次提交的核心内容，长度不宜过长，一般建议不超过50个字符
• 详细描述：进一步解释更改内容，包括动机，目的及实现方式等。应详细说明以便于代码审查和后续理解。

示例

feat(auth): 添加用户登陆功能
新增用户登陆接口及前端登陆页面，支持邮箱和密码验证登陆。

fix(ui)：修复导航栏错位问题
修正了在某些分辨率下导航栏元素对齐不正确的样式问题。

注意事项

• 简洁明了：确保每条Commit信息都是简洁且易于理解的。
• 英文撰写：考虑到开源项目的国际性，推荐使用英文撰写Commit信息。
• 避免合并提交：在合并分支时，尽量使用--no-ff （no fast-forward）选项来创建合并提交，可以保留分支的历史记录。