Git 分支管理与提交信息规范 (v1.0)

为研发团队提供统一、高效的 Git 分支管理和代码提交规范，以实现以下目标：

本规范适用于所有使用 Git 作为版本控制系统的项目及全体研发团队成员。

本规范以 改进的 Git Flow 为核心模型，并介绍了简化的 主干开发 模型供不同场景选择。核心是以下五类分支：

所有分支名称需清晰明了，采用英文小写，连接符使用连字符（-）。

分支类型	命名规范	示例
功能分支	`feature/功能简述-[任务ID]`	`feature/user-login`, `feature/oauth2-support-JIRA-101`
发布分支	`release/版本号`	`release/v1.2.0`, `release/2024.11.0`
热修复分支	`hotfix/问题简述` 或 `hotfix/版本号`	`hotfix/payment-timeout`, `hotfix/v1.0.1`

注意：版本号推荐遵循https://semver.org/lang/zh-CN/。

描述：存放绝对稳定、可随时部署至生产环境的代码。所有官方发布版本都源于此分支。
保护规则 ：
- 设置为 受保护分支。
- 禁止任何形式的直接 push。
- 只能通过合并 发布分支 或 热修复分支 的 Pull Request 来更新。

描述：功能集成的核心分支，包含了所有已完成的、计划在下次发布的新功能。代码应保持相对稳定。
保护规则 ：
- 建议设置为 受保护分支。
- 禁止直接 push。
- 只能通过合并 功能分支 的 Pull Request 来更新。

源分支 ：develop
目标分支 ：develop
工作流程 ：
1. 创建：从最新的 develop 分支切出。git checkout -b feature/awesome-feature develop
2. 开发：在分支上进行常规提交。鼓励频繁、小粒度的提交。
3. 同步：定期从 develop 分支拉取最新代码（建议使用 git pull origin develop --rebase），避免后续合并冲突。
4. 合并：
  - 功能完成后，在代码托管平台（GitLab/GitHub）上向 develop 分支发起 Pull Request。
  - 至少需要一名其他团队成员进行 Code Review 并批准。
  - 合并时，推荐使用 Squash and merge ，将功能分支的所有提交合并为一个清晰的提交记录到 develop 分支，保持历史整洁。
5. 清理：合并成功后，立即删除该功能分支。

源分支 ：develop
目标分支 ：develop 和 main
工作流程 ：
1. 创建：当 develop 分支的功能满足发布条件时，从 develop 切出发布分支。git checkout -b release/v1.2.0 develop
2. 操作：
  - 在此分支上仅允许进行与发布相关的操作：Bug 修复、版本号更新、生成文档等。
  - 严禁添加任何新功能。
  - 在此分支修复的 Bug，需要同步合并回 develop 分支。
3. 发布：测试通过后，将此分支合并回 main 分支，并在 main 上打上标签（Tag），如 v1.2.0。
4. 收尾：将发布分支也合并回 develop（如果期间有修复），确保 develop 包含所有修复。
5. 清理：发布完成后，删除该发布分支。

源分支 ：main 分支上的某个发布标签（如 v1.0.0）。
目标分支 ：main 和 develop
工作流程 ：
1. 创建：从 main 分支切出。git checkout -b hotfix/critical-bug main
2. 修复：进行紧急修复。
3. 合并：
  - 修复完成后，合并到 main 分支，并打上新标签（如 v1.0.1）。
  - 必须同时合并到 develop 分支，确保修复内容不会在后续版本中丢失。如果存在发布分支（release/*），则应优先合并到发布分支。
4. 清理：合并成功后，立即删除热修复分支。

为保持提交历史清晰可读，便于生成变更日志，采用 https://www.conventionalcommits.org/ 规范。

复制代码

<类型>[可选 范围]: <简短描述，使用祈使句，现在时态>

[可选 正文]

[可选 脚注]

类型	描述	示例
`feat`	新增功能	`feat(login): 增加微信扫码登录功能`
`fix`	修复 Bug	`fix(api): 修复用户列表分页错误的问題`
`docs`	文档更新	`docs: 更新 API 接口文档`
`style`	代码风格调整（不影响逻辑）	`style: 按照 ESLint 规则格式化代码`
`refactor`	代码重构（非功能新增、非Bug修复）	`refactor(payment): 重写支付状态判断逻辑`
`perf`	性能优化	`perf: 优化首页图片懒加载性能`
`test`	增加或修改测试	`test(auth): 添加用户登录单元测试`
`chore`	构建流程、工具链变动	`chore: 更新 webpack 配置`

示例：

复制代码

feat(auth): 实现 JWT 令牌自动刷新机制

- 添加令牌过期前自动刷新逻辑
- 增加刷新令牌的 API 接口

Closes #123

对于追求极致持续交付的团队，可考虑 Trunk Based Development 模型。

核心：只有一个长期分支 main。
流程：
1. 所有开发人员从 main 切出短生命周期的功能分支（建议不超过 2 天）。
2. 通过 功能开关 控制新功能的发布与回滚。
3. 完成小功能后，立即创建 PR 合并回 main。鼓励高频率集成。
要求：需要极其完善的自动化测试和 CI/CD 流水线作为保障。
优点：流程简单，集成频率高，合并冲突少。

PR 合并测试/修Bug 发布修Bug时同步线上Bug 修复必须同步 main 初始提交 develop feature/xxx release/v1.0.0 合并至 main 并打 Tag v1.0.0 hotfix/xxx 合并至 main 并打 Tag v1.0.1