用途：为 Git 分支命名提供统一规范，提升可追溯性、便于自动化并让仓库历史更易浏览。适用于创建新功能或修复分支、制定团队分支约定、讨论命名标准；PR 工作流、提交、rebase/merge 策略等应使用其他技能。
命名格式：{type}/{issue}-{short-description}。type 为小写前缀（必填，如 feat、fix）；issue 为 issue 编号，不带 #，存在 issue 时填写；description 使用 kebab-case，2-5 个单词（必填）。示例：feat/123-oauth-login、fix/456-null-pointer-crash、chore/789-update-dependencies、docs/101-api-reference；无 issue 时可写 feat/oauth-integration、fix/memory-leak-cleanup。
分支类型：feat/（新功能）、fix/（缺陷修复）、chore/（维护、依赖、配置）、docs/（仅文档）、refactor/（重构，无行为变化）、test/（测试）、ci/（CI/CD 变更）、hotfix/（生产紧急修复）、release/（发布准备）。
创建方式：git switch -c feat/123-user-authentication；无 issue 时 git switch -c fix/login-timeout-handling；指定基线 git switch -c feat/456-payment-api main、git switch -c hotfix/security-patch production。校验正则：^(feat|fix|chore|docs|refactor|test|ci|hotfix|release)/([0-9]+-)?[a-z0-9]+(-[a-z0-9]+)*$。无效示例：feature/user-auth（应用 feat）、fix/UserAuth（应用 kebab-case）、my-branch（缺类型前缀）、feat/fix_bug（应用连字符）。
issue 关联：GitHub Issues 跟踪的工作应包含编号；Jira、Linear 等外部系统可用 ticket ID（如 feat/PROJ-123-user-dashboard）；探索性工作、无 issue 的快速修复、Dependabot 自动 PR 可不含编号。
描述建议：采用“动作+目标”“组件+变更”“缺陷+上下文”；避免 fix/bug、feat/new-feature 等模糊写法。长度最少类型/issue 后 2 词，最多 5 词、总计约 50 字符，3-4 词较理想。
特殊模式：release/1.0.0、release/2.1.0-beta、release/v3.0.0-rc1；hotfix/security-vulnerability 等；长期分支可加日期后缀如 feat/123-major-refactor-2026q1。团队可选用户前缀：alice/feat/123-oauth 或 feat/alice-oauth-integration。建议对 main、master、develop、release/、hotfix/ 配置分支保护。
自动化：分支类型可映射提交 scope（feat/123-auth → feat(auth): ...）；CI 可按 'feat/'、'fix/'、'hotfix/**' 触发。常用命令：git branch --list 'feat/*'、git branch -d feat/123-description、git push origin --delete feat/123-description、git branch -m old-name new-name。
限制：资料未提供该技能的安装方式、平台支持、收费与效果数据。