Git 分支策略与规范

概述选择合适的分支策略与提交规范是规模化协作的关键。本文对比 GitFlow 与 Trunk-Based 两种模型，给出规范与落地建议。分支模型GitFlow：适合版本节奏明确与发布周期较长的团队；`main`/`develop`/`feature`/`release`/`hotfix`。Trunk-Based：主干开发，小步快跑，短生命周期的 `feature` 分支，强依赖自动化测试与代码评审。提交与版本规范（已验证）语义化版本（SemVer）：`MAJOR.MINOR.PATCH`；破坏性变更升级主版本，新特性次版本，修复补丁。Conventional Commits：<type>(scope): <subject> feat(auth): add OAuth2 login fix(ci): correct pipeline cache key docs(readme): update usage examples 合并策略：`rebase` 保持线性历史，适合主干开发；`merge --no-ff` 保留合并记录，适合 GitFlow 的 release 管理。保护主干与流程保护分支：强制 PR、评审与 CI 通过；禁止直接推送到 `main`。检查：必须通过单测、静态检查与安全扫描；要求最少两名评审者。发布与回滚采用 `tag` 与发布说明（Release Notes）；回滚使用 `revert` 保持审计友好。为长期维护版本（LTS）设置分支与补丁窗口。注意事项团队规模、发布节奏与合规要求决定分支模型选择；应定期回顾与调整。规范落地需配合 CI/CD 与代码评审工具的强制策略。