对于大多数团队协作项目，推荐采用 Git Flow 或简化版的分支模型，核心原则是保护主分支不被直接修改，通过功能分支隔离开发风险。

分支命名正则规范

统一的命名规则有助于自动化脚本识别与权限控制。建议在仓库钩子或 CI 流程中通过正则校验分支名。

^(feature|bugfix|hotfix|release)\/[a-z0-9-]+$

• feature/：新功能开发，基于 develop 分支
• bugfix/：测试阶段 Bug 修复，基于 develop 分支
• hotfix/：线上紧急修复，基于 master 分支
• release/：发布预演，基于 develop 分支

核心命令与场景

日常开发中，区分 merge 与 rebase 的使用场景至关重要。公共分支禁止变基，本地提交可整理历史。

git checkout -b feature/xxx develop
git merge `--no-ff` feature/xxx
git branch -d feature/xxx

注意：合并功能分支到主分支时建议使用 `--no-ff` 保留合并记录，便于后续回滚与审计。严禁在公共分支（如 develop/master）上使用 git rebase，以免破坏共享历史。

分支保护策略配置

防止误操作导致主线污染，需在代码托管平台开启保护规则。

GitHub 设置路径：Settings -> Branches -> Add rule

GitLab 设置路径：Settings -> Repository -> Protected Branches

关键配置项：

• Branch name pattern: master 或 main
• Allow force pushes: 禁止 (Unchecked)
• Allow deletions: 禁止 (Unchecked)
• Require pull request reviews before merging: 开启 (至少 1 人)
• Require status checks to pass before merging: 开启 (CI 流水线)

Commit 消息规范详解

规范的提交信息有助于生成 changelog 与快速定位问题。可引入 commitlint 进行本地校验。

commitlint.config.js 示例：

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [2, 'always', ['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore']],
    'subject-full-stop': [2, 'never', '.'],
    'header-max-length': [2, 'always', 100]
  }
};

验证与常见坑

验证方法：

1. 使用 git log `--graph` `--oneline` 查看分支合并历史，确认存在合并节点而非快进。
2. 检查 CI/CD 流水线状态，确保合并请求触发自动化测试且通过。
3. 验证 master 分支是否有对应的版本标签（如 v1.0.0）。

常见坑与排查：

• 直接向 master 推送代码：通常因保护规则未生效导致，检查平台分支保护设置是否保存。
• 分支命名随意：导致后期无法识别用途，建议在 pre-commit 钩子中加入分支名校验脚本。
• 合并后未删除分支：造成仓库冗余，合并成功后立即执行 git branch -d 或在 PR 设置中勾选自动删除。
• 解决冲突丢失代码：解决冲突时仅保留当前分支代码，务必对比双方差异，使用 git diff 确认无误后再提交。
• 公共分支 Rebase：导致同事本地历史冲突，公共分支只合并不变基。

参考来源

• Git 官方文档 - 分支开发工作流 (https://git-scm.com/book/zh/v2)
• Atlassian Git Tutorial - Git Flow (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)
• Commitlint 官方配置文档 (https://commitlint.js.org/)
• GitHub Docs - 关于受保护的分支 (https://docs.github.com/)