git-flow 是一个 Git 工作流实践指南型技能，适用于提交代码、创建分支、发起 PR 或决定合并与分支策略时参考。
用途与定位 该技能以 2026 年 Git Flow 最佳实践为内容基础，用于指导团队和个人在 Git 协作中统一分支、提交、合并与发布行为。
工作流选择 技能对三种常见策略给出判断：主干开发（直接提交 main）适用于单人开发、原型或 CI 较强的项目；GitHub Flow（功能分支→PR→合并→删除）适合团队、开源项目和需要代码审查的场景，被列为默认推荐；传统 Git Flow（develop/release/hotfix）适合发布周期重的项目，但被认为对多数项目已过时。默认策略为 GitHub Flow。
分支命名规范 分支采用 <type>/<scope-or-summary> 格式，仅用小写 kebab-case，总长度小于 50 字符。类型包括 feat、fix、chore、docs、refactor、perf、test、ci、build、style，并给出示例。规则要求不使用个人前缀，也不单独用 issue 编号命名。
受保护分支 main、master、develop、production 不允许直接提交。技能描述了一套检测当前分支、对受保护分支进行拦截并建议自动命名功能分支的机制，同时列出单人原型、显式跳过检查、提交后版本号递增等例外情况。
分支生命周期与合并策略 生命周期为创建分支、提交、推送上游、创建 PR、审查与 CI、合并并删除分支，建议分支保持短生命周期。合并默认使用真实 merge commit，而非 squash，原因是 squash 会使指向版本递增提交的发布标签失去目标；rebase merge 适用于保留小型原子提交的场景。
合并前 CI 校验 技能强调合并前必须确认 CI 检查状态，不能假定“零 CI”。它区分三种情况：仓库在分支保护中配置了必需状态检查时，可使用 --auto 由服务端等待必需检查；有检查但未被标记为必需时，需要客户端轮询检查注册后再 watch，避免 gh pr checks --watch 紧随 gh pr create 导致的竞态；确认零 CI 时可直接合并。还给出轮询脚本示例，并提醒不要将最终的 watch 调用接入管道，以免吞掉退出码。
发布与标签 标签应在合并验证完成后于 main 上创建并推送，避免标签指向未落地的提交。推送标签后还需跟踪标签触发的发布工作流，作者给出查看运行、监视、失败分类与重跑的操作流程，并在最终全部通过且包注册表返回对应版本后才视为“已发布”。
合并后处理与 PR 模板 合并后删除远程与本地分支，拉取 main，并提供包含摘要、变更、测试计划和破坏性变更的 PR 模板。
反模式 列出长期存活分支、直接在 main 提交、强推 main、无意义分支名、无描述 PR、团队中未经审查自合并、过期分支等反模式。
单人开发 单人仓库仍建议使用功能分支作为回滚保障，可自审 PR 做检查，或在 CI 较强时提交后直接推送 main。
限制 该技能为工作流规范与操作指引，不提供自动执行全部步骤的独立程序；部分命令和行为依赖 GitHub CLI 及仓库分支保护配置，具体项目中的参数与阈值需要按实际情况调整。