Git 分支管理及命名规范应该如何制定？

制定 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-]+$'; then
    echo "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-latest
    steps:
      - name: Check Branch Name
        run: |
          if [[ ! ${{ github.head_ref }} =~ ^(feature|bugfix|hotfix)/ ]]; then
            echo "Branch name does not match convention"
            exit 1
          fi

分支保护设置：在 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