制定 Git 分支规范没有唯一标准，小团队建议直接用 GitHub Flow 简化流程，多版本并行的大型项目才需要考虑 Git Flow。核心在于通过自动化手段减少人为失误。
先说结论：规范的核心是平衡协作效率与发布风险，而不是追求流程复杂。
- 适合：3 人以上协作或需要频繁发布的项目
- 先准备：统一分支命名前缀与保护策略
- 验收：通过 CI 流水线卡点与代码审查
工作流模型选择
根据团队规模选择模型，避免过度设计：
- GitHub Flow：适合持续部署。只有 main 和 feature 分支，合并即发布。
- Git Flow：适合传统发布周期。包含 develop、release、hotfix 等分支，适合多版本并行维护。
命名规范与本地自动化校验
仅靠文档约束容易失效，建议通过 Git Hook 在本地提交前校验分支命名。建议格式：类型/描述，例如 feature/user-auth、bugfix/login-error。
正则表达式示例：
^(feature|bugfix|hotfix|release)\/[a-z0-9-]+$Git Hook 脚本示例 (.git/hooks/pre-push)：
#!/bin/sh
branch=$(git symbolic-ref `--short` HEAD)
if ! echo "$branch" | grep -qE '^(feature|bugfix|hotfix)\/[a-z0-9-]+$'; thenecho "ERROR: 分支命名不符合规范，请使用 类型/描述 格式"exit 1
fi远程保护与 CI 流水线配置
在代码托管平台设置分支保护，禁止直接 Push 到主分支，并配置 CI 流水线作为合并卡点。
GitHub Actions 配置示例 (.github/workflows/branch-check.yml)：
name: Branch Check
on: [pull_request]
jobs:check:runs-on: ubuntu-lateststeps:- name: Check Branch Namerun: |if [[ ! ${{ github.head_ref }} =~ ^(feature|bugfix|hotfix)/ ]]; thenecho "Branch name does not match convention"exit 1fi分支保护设置：在 Settings -> Branches 中，添加规则保护 main 分支，勾选 "Require a pull request before merging" 和 "Require status checks to pass before merging"。
团队规范文档模板
可将以下片段放入团队 Wiki 或 README 中：
## 分支管理规范
1. 主分支：main (受保护，禁止直接推送)
2. 功能分支：feature/功能描述 (例如 feature/order-module)
3. 修复分支：bugfix/问题描述 (例如 bugfix/payment-timeout)
4. 生命周期：分支合并后 24 小时内删除远程分支验证与常见坑
验证方法：
- 尝试直接向 main 分支推送代码，若被服务器拒绝则保护生效。
- 创建不符合命名规范的分支并推送，检查 CI 流水线是否报错拦截。
- 检查 CI 流水线是否在合并请求时自动触发测试。
常见坑：
- 分支长期不合并：功能分支存在超过两周未合并，后续冲突风险会显著增加。
- 命名随意：使用 test、tmp 等无意义名称，导致后期无法清理。
- 忽略删除：合并后未及时删除远程分支，导致仓库分支列表杂乱。
参考来源
- Atlassian Git Tutorial, What is Git Flow?, https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
- GitHub Docs, GitHub Flow, https://docs.github.com/en/get-started/quickstart/github-flow
原文链接：https://www.zjcp.cc/ask/11322.html