Git 工作流 #

这一页是团队 Git 协作的唯一规则页面，覆盖分支、提交、PR 与评审门禁。

分支策略 #

main 作为稳定分支，只用于可发布代码
dev 作为日常开发主分支
新功能使用 feature/* 分支
问题修复使用 fix/* 分支

开发流程 #

从 dev 切出 feature/* 或 fix/*
在个人分支完成开发与自测
提交 Pull Request 合并回 dev
验证通过后再由负责人从 dev 合并到 main

PR 规则 #

所有代码变更必须通过 PR 合并
禁止直接向 main 推送业务改动
合并前至少 1 人 Review
PR 描述必须写明改动内容与验证方式

PR 模板示例 #

以下是可直接复用的 Pull Request 模板，可放在仓库的 .github/pull_request_template.md 中。

<!-- 标题请写本次改动的简要总结 -->

## 变更说明
<!-- 详细描述本次改动 -->

## 变更动机与背景
<!-- 为什么需要这个改动？解决了什么问题？ -->
<!-- 如果修复了某个 Issue，请在这里关联。 -->

## 测试方式
<!-- 详细说明你如何测试本次改动。 -->
<!-- 包括测试环境、执行过的测试，以及对其他模块的影响验证。 -->

## 变更类型
<!-- 请选择所有适用项，在方框内填 x -->
- [ ] Bug 修复（不破坏现有功能）
- [ ] 新功能（不破坏现有功能）
- [ ] 破坏性变更（会影响现有功能行为）

## 检查清单
<!-- 请逐项确认，在方框内填 x -->
<!-- 如不确定，可在 PR 中说明。 -->
- [ ] 代码遵循本项目代码风格。
- [ ] 本次改动需要更新文档。
- [ ] 已同步更新相关文档。
- [ ] 已添加覆盖本次改动的测试。
- [ ] 所有新旧测试均已通过。

Commit 规则 #

使用清晰的结构化前缀，例如 feat:、fix:、docs:、refactor:
一次提交只做一类变更
禁止使用含糊描述，例如 update、change

Review 检查项 #

逻辑是否正确
接口或数据结构是否与既有约定一致
是否破坏已有行为
文档是否需要同步更新

合并门禁 #

dev 用于集成和联调，不通过检查不进入 main
main 只接收经过评审和验证的改动
质量门禁不通过时，不允许例外合并