5.1 版本控制与代码提交规范

优秀的版本控制应当像一本条理清晰的编年史，任何人在任何时候接手代码，都能通过 Git 历史精准还原业务的演进过程。本规范旨在建立清晰、可追溯、自动化的代码流转体系。

为了兼顾敏捷交付与生产环境的极度稳定，团队统一采用 简化的 GitFlow / 环境变量流 (Environment Flow)。

这三个核心分支与部署环境严格绑定，绝对禁止任何开发人员直接使用 git push 推送代码，必须通过 PR/MR 流程合并：

main (或 master) - 生产环境分支：
- 对应线上生产环境 (Production)。
- 这里的代码必须是随时可发布、经过全面测试的绝对稳定版本。
test (或 release) - 测试/预发环境分支：
- 对应 QA 测试环境或预发布环境 (Staging)。
- 用于产品经理验收和测试工程师进行系统级回归测试。
dev (或 develop) - 开发集成环境分支：
- 对应日常开发联调环境。
- 汇总所有开发人员最新的 Feature 代码，允许存在一定的 Break Change，但必须保证编译和基础启动不报错。

开发人员日常编码都在临时分支上进行，命名必须遵循以下前缀规范，并在开发完成后删除：

feat/xxx：新功能开发分支（从 dev 检出，合并回 dev）。
- 示例：feat/user-login-wechat
fix/xxx：常规 Bug 修复分支（从 dev 或 test 检出）。
- 示例：fix/order-amount-calc-error
hotfix/xxx：线上紧急漏洞修复分支（直接从 main 检出）。
- 红线：紧急修复测试通过后，必须同时双向合并到 main 和 dev 分支，防止代码覆盖丢失！

核心理念：让机器能读懂提交历史，以便自动生成 Release Notes。

团队强制遵循 Angular 提交规范。推荐在项目中引入 commitlint 配合 Git Hooks（如 pre-commit）进行强制拦截。

用于说明本次提交影响的模块，如 (user), (order-service), (ci)。

红线：严禁人肉编造随意字符串作为版本号。 所有对外发布、打包上线的制品（如 Docker 镜像、NPM 包、Maven 依赖）必须严格遵循 语义化版本 (SemVer 2.0.0) 规范。

示例：v1.0.0 -> v1.1.0 (加了新功能) -> v1.1.1 (修了新功能的 Bug) -> v2.0.0 (接口大重构，老版本客户端不可用)。

在正式 Tag 之前，如果是处于测试阶段的里程碑，应当追加连字符与标识：

为配合 4.2 代码审查规范与 CI/CD 质量门禁，特设立以下代码流转纪律：

防门禁失败兜底 (Pre-commit)：
- 所有代码在 git commit 时，必须触发本地钩子验证。如项目存在特定的门禁脚本（如 GTCO_AI 项目下的 scripts/ci/quality_gate.sh），必须在本地保证执行通过。
禁止强推 (No Force Push)：
- 绝对禁止对 dev, test, main 等公共分支执行 git push -f。此行为将直接导致团队其他成员的版本库断裂。
主张 Squash Merge (压缩合并)：
- 开发者在自己的 feat/xxx 分支上为了备份，可能会产生大量零碎的 commit（如 fix typo, update again）。
- 在通过 PR 合并到主干分支（如 dev）时，强烈建议使用 Squash and Merge，将无数琐碎的 commit 压缩成一个整洁的业务 Commit 记录进入主干。
及时变基 (Rebase / Sync)：
- 开发周期较长的 Feature 分支，必须每天从目标主干分支拉取最新代码（建议使用 git pull --rebase origin dev），提前解决冲突，严禁等到提 PR 那天才去处理几千行的灾难性冲突。