使用 Conventional Branch 规范创建 Git 分支awesome-copilot 仓库技能实战指南【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot导读本文基于开源仓库 awesome-copilot 中社区贡献的 Agent Skill技能skills/conventional-branch/SKILL.md系统讲解 Conventional Branch约定式分支规范如何按type/description格式命名 Git 分支、五种分支类型的适用场景、主干分支的识别与使用、命名规则的边界与反例以及一套可直接落地的五步分支创建工作流。读完本文你将能够在日常开发与 AI 辅助编程中让 Copilot 或任何 Agent 依照统一规范创建、校验、命名 Git 分支并与 Conventional Commits约定式提交配套使用形成从分支到提交的完整工程约束。技能定位Agent 如何被触发在 awesome-copilot 仓库中该技能以 SKILL.md 的形式发布属于 Agent Skills 规范定义的自包含指令文件夹Agent 在需要时按需加载progressive disclosure。其 frontmatter 中的description定义了触发条件创建新分支creating a new branch为分支命名naming a branch检查分支名是否符合规范checking whether a branch name complies with the spec当用户提出帮我建一个分支给这个分支起个名字这个分支名规范吗之类的请求时Agent 会加载本技能按其中的规则生成符合 Conventional Branch 规范的分支名。技能的完整安装与使用方式见仓库的 docs/README.skills.md既可以通过 GitHub CLI 执行gh skills install github/awesome-copilot conventional-branch要求 GitHub CLI v2.90.0也可以手动将技能文件夹复制到本地 skills 目录。分支命名格式type/descriptionConventional Branch 规范的核心只有一条所有非主干分支的名称必须遵循type/descriptiontype分支类型前缀决定这条分支承载的工作性质/类型与描述之间的固定分隔符description对分支工作内容的简短描述使用 kebab-case。五种分支类型类型别名用途feature/feat/新功能或增强New features or enhancementsbugfix/fix/Bug 修复Bug fixeshotfix/—紧急生产修复Urgent production fixesrelease/—发布准备Release preparation版本描述中允许出现点号如release/v1.2.0chore/—非代码类任务Non-code tasks如依赖升级、文档、配置变更需要特别注意的是bugfix/与hotfix/不能混用。bugfix/处理常规 Bug走正常的开发节奏hotfix/专指需要紧急上线的生产问题修复命名语义上的区分直接影响团队的响应优先级与审批流程。主干分支Trunk Branchesmain、master、develop属于主干分支不使用任何前缀。主干分支是整个仓库的主线应当直接从它们切出工作分支而不是创建与主干重名的新分支——例如永远不要执行git checkout -b main去新建一个main。命名规则六条硬性约束无论分支类型如何描述部分都必须满足以下命名规则仅小写Lowercase only——任何位置都不允许大写字母字符白名单——只允许a-z、0-9、-、.点号仅限 release 版本——.只允许出现在release/的版本描述中如release/v1.2.0其他类型的分支描述禁止使用点号禁止下划线、空格与特殊字符禁止连字符/点号的连续与相邻——不允许连续连字符--、连续点号..也不允许-.或.-这种连字符与点号紧邻的组合描述首尾禁止连字符或点号。从实现角度看这些规则本质上定义了一个严格的正则字符集[a-z0-9-.]并叠加了.仅限 release、无连续分隔符、无首尾分隔符三条位置约束。Agent 在自动命名分支时正是靠这些规则做归一化处理。合法与非法示例对照合法示例main master develop feature/add-login-page feat/add-login-page bugfix/fix-header-bug fix/header-bug hotfix/security-patch release/v1.2.0 chore/update-dependencies feature/issue-123-new-login注意最后一条feature/issue-123-new-login把 ticket/issue 编号直接纳入描述这是跨团队追溯需求来源的常用做法本文工作流一节会再展开。非法示例及原因分支名违规原因Feature/Add-Login大写字母feature/new--login连续连字符feature/-new-login描述以连字符开头feature/new-login-描述以连字符结尾release/v1.-2.0连字符与点号相邻fix/header bug包含空格fix/header_bug包含下划线unknown/some-task未知前缀类型这组对照非常实用它不仅告诉 Agent 什么是合规的还通过反例明确了判定边界避免把header_bug这类含下划线的名字误判为合规。当 Agent 被要求检查这个分支名是否符合规范时就是逐条比对这些规则的。Description 编写指南kebab-case 与信息密度分支描述部分建议遵循以下原则使用kebab-case连字符连接的小写单词长度控制在25 个单词描述要具体但克制整条分支名总长度约50 个字符以内好的例子add-oauth-login、fix-header-overflow、update-ci-config差的例子fix-bug太笼统没说明修什么、new-feature没说明做什么功能。这条反笼统的准则与 Conventional Commits 规范中description 必须使用祈使语气、说明变更意图的精神一致分支名与提交信息一样都是给未来的自己和协作者读的信息密度不足的名字会让仓库历史失去可检索价值。五步工作流从需求到分支落地技能提供了一套完整的、可直接执行的分支创建流程Agent 需要按顺序完成以下五个步骤Step 1 — 确定分支类型若用户没有明确说明先询问两个问题分支类型——不确定时默认使用feature简短描述——这条分支要做什么。如果用户提到了 ticket 或 issue 编号将其纳入描述例如feature/issue-123-add-oauth。这保证了分支名与需求管理系统可双向追溯。Step 2 — 校验名称将组装好的分支名与上述命名规则逐条比对任何一条不满足就立即修正全部转为小写将下划线和空格替换为连字符合并连续连字符去除首尾连字符。这套修正顺序也是 Agent 生成名字时的推荐流水线先归一化字符再做去重与修剪。Step 3 — 探测基分支Base Branch不同仓库的主干分支命名习惯不同develop、main、master都有可能先探测当前仓库实际使用哪个# 优先采用远程仓库的默认分支 git symbolic-ref --short refs/remotes/origin/HEAD 2/dev/null | sed s|^origin/||如果上面命令没有输出再按优先级顺序develop→main→master检查本地存在哪个主干分支for b in develop main master; do git show-ref --verify --quiet refs/heads/$b echo $b break done从源码角度解读第一条命令读取远程origin的 HEAD 符号引用refs/remotes/origin/HEAD这是远程仓库默认分支的最权威来源第二条命令回退到本地分支引用refs/heads/探测。两步构成了远程优先、本地兜底的稳健探测策略保证了在新仓库、克隆仓库或本地初始化仓库中都能得到正确基分支。Step 4 — 创建并切换确认基分支后执行git checkout base git pull origin base git checkout -b type/description三步分别完成切换到基分支、拉取远端最新状态避免基于过期主干切分支、从最新主干创建并切换到新分支。Step 5 — 确认与提醒创建完成后向用户确认新创建的分支名当前已处于该新分支提醒用户准备好后执行git push -u origin branch-name首次推送。与 Conventional Commits 的关系分支与提交的配套约束Conventional Branch 与 Conventional Commits 是同一套工程纪律的两个环节分支命名管在哪儿开发提交信息管每步改了什么。两者的类型体系天然对齐Conventional Branch典型的 Conventional Commitfeature/add-loginfeat: add login pagebugfix/fix-headerfix: header overflow on mobilechore/update-depschore: bump lodash to 5.0release/v1.2.0chore: release v1.2.0技能明确建议分支类型尽量与提交类型保持一致例如feature/*分支内提交feat:类型的 commit。这样从分支名到提交信息形成一致的语义链CI 校验、版本自动生成semantic-release 类工具、代码评审都能获得可靠的输入信号。在 awesome-copilot 仓库中这一配套体系还有更多落地方案可以组合使用skills/conventional-commit/SKILL.md以 XML 结构化格式生成符合 Conventional Commits 规范的提交信息定义了feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert十一种类型并约束 description 必须使用祈使语气、scope 可选但推荐——与本技能的feature/、bugfix/、chore/分支类型一一对应skills/git-commit/SKILL.md从git diff自动检测变更类型与 scope智能暂存并生成约定式提交信息skills/commit-message-storyteller/SKILL.md生成叙事化但同样遵循 Conventional Commits 格式的提交信息skills/git-flow-branch-creator/SKILL.md基于 nvie Git Flow 分支模型的智能分支创建器分析git status/git diff后自动确定分支类型并创建语义化分支名——与本技能关注 Conventional Branch 规范不同它侧重变更内容的自动分类两者可以互为补充。在 AI 辅助开发中的典型用法将本技能与 Copilot 或其他编码 Agent 配合时典型的交互路径是命名为给登录页添加 OAuth 支持这个任务创建一个分支——Agent 按规范生成feature/add-oauth-login校验检查Feature/Add-Login这个分支名是否合规——Agent 逐条对照命名规则指出大写字母违规修正帮我修正fix/header_bug这个分支名——Agent 将下划线替换为连字符输出fix/header-bug全流程直接说为 issue-123 建一个修复分支Agent 会依次完成类型确认默认feature或按语义判定为bugfix、名称校验、基分支探测Step 3 的两条命令、git checkout -b创建切换最后提示git push -u origin。由于技能遵循 Agent Skills 规范、支持渐进式加载Agent 只在处理分支相关请求时加载本指令不会增加无关对话的上下文开销。若需向仓库贡献新的技能或改进现有技能可参考 CONTRIBUTING.md 中的 guidelines。结语Conventional Branch 的价值不在命名本身而在于把分支名变成团队可机器校验、可自动化的语义元数据CI 可以依据前缀决定是否触发特定流水线发布脚本可以识别release/分支执行版本流程代码评审可以快速判断一条分支的意图。配合本仓库提供的 conventional-commit、git-commit 等技能你可以把分支 提交的命名纪律完整交给 Agent 执行让规范真正落地为团队日常开发的一部分。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考