企业官网建设流程全解析

使用 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>/<description>

Conventional Branch 规范的核心只有一条：所有非主干分支的名称必须遵循

<type>/<description>

• <type>：分支类型前缀，决定这条分支承载的工作性质；
• /：类型与描述之间的固定分隔符；
• <description>：对分支工作内容的简短描述，使用 kebab-case。

五种分支类型

需要特别注意的是：bugfix/与hotfix/不能混用。bugfix/处理常规 Bug，走正常的开发节奏；hotfix/专指需要紧急上线的生产问题修复，命名语义上的区分直接影响团队的响应优先级与审批流程。

主干分支（Trunk Branches）

main、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 编号直接纳入描述，这是跨团队追溯需求来源的常用做法，本文"工作流"一节会再展开。

非法示例及原因

这组对照非常实用：它不仅告诉 Agent "什么是合规的"，还通过反例明确了判定边界，避免把header_bug这类含下划线的名字误判为合规。当 Agent 被要求"检查这个分支名是否符合规范"时，就是逐条比对这些规则的。

Description 编写指南：kebab-case 与信息密度

分支描述部分建议遵循以下原则：

• 使用kebab-case（连字符连接的小写单词），长度控制在2～5 个单词；
• 描述要具体但克制，整条分支名总长度约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 是同一套工程纪律的两个环节：分支命名管"在哪儿开发"，提交信息管"每步改了什么"。两者的类型体系天然对齐：

技能明确建议：分支类型尽量与提交类型保持一致，例如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 配合时，典型的交互路径是：

1. 命名："为'给登录页添加 OAuth 支持'这个任务创建一个分支"——Agent 按规范生成feature/add-oauth-login；
2. 校验："检查Feature/Add-Login这个分支名是否合规"——Agent 逐条对照命名规则，指出大写字母违规；
3. 修正："帮我修正fix/header_bug这个分支名"——Agent 将下划线替换为连字符，输出fix/header-bug；
4. 全流程：直接说"为 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