git-flow-branch-creator by github/awesome-copilot
npx skills add https://github.com/github/awesome-copilot --skill git-flow-branch-creator请遵循以下步骤:
git status 以查看当前仓库状态和已更改的文件。git diff(针对未暂存的变更)或 git diff --cached(针对已暂存的变更)来分析变更的性质。 <release>
<purpose>发布准备、版本号更新、最终测试</purpose>
<branch-from>develop</branch-from>
<merge-to>develop AND master</merge-to>
<naming>release-X.Y.Z</naming>
<indicators>
<indicator>版本号变更</indicator>
<indicator>构建配置更新</indicator>
<indicator>文档定稿</indicator>
<indicator>发布前的次要错误修复</indicator>
<indicator>发布说明更新</indicator>
<indicator>依赖版本锁定</indicator>
</indicators>
</release>
<hotfix>
<purpose>需要立即部署的关键生产环境错误修复</purpose>
<branch-from>master</branch-from>
<merge-to>develop AND master</merge-to>
<naming>hotfix-X.Y.Z 或 hotfix/关键问题-描述</naming>
<indicators>
<indicator>安全漏洞修复</indicator>
<indicator>关键生产环境错误</indicator>
<indicator>数据损坏修复</indicator>
<indicator>服务中断解决</indicator>
<indicator>紧急配置变更</indicator>
</indicators>
</hotfix>
</branch-types>
</analysis-framework>
<naming-conventions>
<feature-branches>
<format>feature/[工单号-]描述性名称</format>
<examples>
<example>feature/user-authentication</example>
<example>feature/PROJ-123-shopping-cart</example>
<example>feature/api-rate-limiting</example>
<example>feature/dashboard-redesign</example>
</examples>
</feature-branches>
</naming-conventions>
<analysis-process>
<step-1>
<title>变更性质分析</title>
<description>检查修改的文件类型和变更的性质</description>
<criteria>
<files-modified>查看文件扩展名、目录结构和用途</files-modified>
<change-scope>确定变更是增量的、纠正性的还是准备性的</change-scope>
<urgency-level>评估变更是否解决关键问题或是开发性的</urgency-level>
</criteria>
</step-1>
</analysis-process>
<edge-cases>
<mixed-changes>
<scenario>变更同时包含功能和错误修复</scenario>
<resolution>优先考虑最重要的变更类型,或建议拆分为多个分支</resolution>
</mixed-changes>
</edge-cases>
<examples>
<example-1>
<scenario>添加了新的用户注册 API 端点</scenario>
<analysis>新功能,增量变更,非关键性</analysis>
<branch-type>feature</branch-type>
<branch-name>feature/user-registration-api</branch-name>
<command>git checkout -b feature/user-registration-api develop</command>
</example-1>
</examples>
<validation>
<pre-analysis>
<check>仓库处于干净状态(没有会冲突的未提交变更)</check>
<check>当前分支是合适的起点(feature/release 从 develop 分支,hotfix 从 master 分支)</check>
<check>远程仓库是最新的</check>
</pre-analysis>
</validation>
<execution-protocol>
<analysis-summary>
<git-status>`git status` 命令的输出</git-status>
<git-diff>`git diff` 输出的相关部分</git-diff>
<change-analysis>变更所代表内容的详细分析</change-analysis>
<branch-decision>解释为何选择特定分支类型</branch-decision>
</analysis-summary>
</execution-protocol>
<gitflow-reference>
<main-branches>
<master>生产就绪代码,每次提交都是一个发布版本</master>
<develop>用于功能集成的分支,最新的开发变更</develop>
</main-branches>
</gitflow-reference>
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
<release-branches>
<format>release-X.Y.Z</format>
<examples>
<example>release-1.2.0</example>
<example>release-2.1.0</example>
<example>release-1.0.0</example>
</examples>
</release-branches>
<hotfix-branches>
<format>hotfix-X.Y.Z 或 hotfix/关键-描述</format>
<examples>
<example>hotfix-1.2.1</example>
<example>hotfix/security-patch</example>
<example>hotfix/payment-gateway-fix</example>
<example>hotfix-2.1.1</example>
</examples>
</hotfix-branches>
<step-2>
<title>Git Flow 分类</title>
<description>将变更映射到适当的 Git Flow 分支类型</description>
<decision-tree>
<question>这些是针对生产环境问题的关键修复吗?</question>
<if-yes>考虑 hotfix 分支</if-yes>
<if-no>
<question>这些是发布准备变更(版本号更新、最终调整)吗?</question>
<if-yes>考虑 release 分支</if-yes>
<if-no>默认使用 feature 分支</if-no>
</if-no>
</decision-tree>
</step-2>
<step-3>
<title>分支名称生成</title>
<description>创建语义化、描述性的分支名称</description>
<guidelines>
<use-kebab-case>使用小写字母和连字符</use-kebab-case>
<be-descriptive>名称应清晰表明目的</be-descriptive>
<include-context>在可用时添加工单号或项目上下文</include-context>
<keep-concise>避免名称过长</keep-concise>
</guidelines>
</step-3>
<no-changes>
<scenario>在 git status/diff 中未检测到变更</scenario>
<resolution>通知用户并建议先检查 git status 或进行变更</resolution>
</no-changes>
<existing-branch>
<scenario>已处于 feature/hotfix/release 分支上</scenario>
<resolution>分析是否需要新分支,或者当前分支是否合适</resolution>
</existing-branch>
<conflicting-names>
<scenario>建议的分支名称已存在</scenario>
<resolution>追加增量后缀或建议替代名称</resolution>
</conflicting-names>
<example-2>
<scenario>修复了身份验证中的关键安全漏洞</scenario>
<analysis>安全修复,对生产环境关键,需要立即部署</analysis>
<branch-type>hotfix</branch-type>
<branch-name>hotfix/auth-security-patch</branch-name>
<command>git checkout -b hotfix/auth-security-patch master</command>
</example-2>
<example-3>
<scenario>将版本更新为 2.1.0 并最终确定了发布说明</scenario>
<analysis>发布准备,版本号更新,文档</analysis>
<branch-type>release</branch-type>
<branch-name>release-2.1.0</branch-name>
<command>git checkout -b release-2.1.0 develop</command>
</example-3>
<example-4>
<scenario>改进了数据库查询性能并更新了缓存</scenario>
<analysis>性能改进,非关键性增强</analysis>
<branch-type>feature</branch-type>
<branch-name>feature/database-performance-optimization</branch-name>
<command>git checkout -b feature/database-performance-optimization develop</command>
</example-4>
<analysis-quality>
<check>变更分析覆盖所有已修改的文件</check>
<check>分支类型选择遵循 Git Flow 原则</check>
<check>分支名称具有语义并遵循约定</check>
<check>已考虑并处理边界情况</check>
</analysis-quality>
<execution-safety>
<check>目标分支(develop/master)存在且可访问</check>
<check>建议的分支名称与现有分支不冲突</check>
<check>用户拥有创建分支的适当权限</check>
</execution-safety>
<branch-creation>
<command>git checkout -b [分支名称] [源分支]</command>
<confirmation>验证分支创建和当前分支状态</confirmation>
<next-steps>提供后续操作指导(提交变更、推送分支等)</next-steps>
</branch-creation>
<fallback-options>
<alternative-names>如果主要建议不合适,提供 2-3 个替代分支名称建议</alternative-names>
<manual-override>如果分析似乎不正确,允许用户指定不同的分支类型</manual-override>
</fallback-options>
<supporting-branches>
<feature>从 develop 分支创建,合并回 develop</feature>
<release>从 develop 分支创建,合并到 develop 和 master</release>
<hotfix>从 master 分支创建,合并到 develop 和 master</hotfix>
</supporting-branches>
<merge-strategy>
<flag>始终使用 `--no-ff` 标志以保留分支历史</flag>
<tagging>在 master 分支上标记发布版本</tagging>
<cleanup>成功合并后删除分支</cleanup>
</merge-strategy>
每周安装量
7.5K
仓库
GitHub 星标数
26.9K
首次出现
2026年2月25日
安全审计
安装于
codex7.4K
gemini-cli7.4K
opencode7.3K
cursor7.3K
github-copilot7.3K
amp7.3K
<instructions>
<title>Git Flow Branch Creator</title>
<description>This prompt analyzes your current git changes using git status and git diff (or git diff --cached), then intelligently determines the appropriate branch type according to the Git Flow branching model and creates a semantic branch name.</description>
<note>
Just run this prompt and Copilot will analyze your changes and create the appropriate Git Flow branch for you.
</note>
</instructions>
Follow these steps:
git status to review the current repository state and changed files.git diff (for unstaged changes) or git diff --cached (for staged changes) to analyze the nature of changes.<analysis-framework>
<branch-types>
<feature>
<purpose>New features, enhancements, non-critical improvements</purpose>
<branch-from>develop</branch-from>
<merge-to>develop</merge-to>
<naming>feature/descriptive-name or feature/ticket-number-description</naming>
<indicators>
<indicator>New functionality being added</indicator>
<indicator>UI/UX improvements</indicator>
<indicator>New API endpoints or methods</indicator>
<indicator>Database schema additions (non-breaking)</indicator>
<indicator>New configuration options</indicator>
<indicator>Performance improvements (non-critical)</indicator>
</indicators>
</feature>
<release>
<purpose>Release preparation, version bumps, final testing</purpose>
<branch-from>develop</branch-from>
<merge-to>develop AND master</merge-to>
<naming>release-X.Y.Z</naming>
<indicators>
<indicator>Version number changes</indicator>
<indicator>Build configuration updates</indicator>
<indicator>Documentation finalization</indicator>
<indicator>Minor bug fixes before release</indicator>
<indicator>Release notes updates</indicator>
<indicator>Dependency version locks</indicator>
</indicators>
</release>
<hotfix>
<purpose>Critical production bug fixes requiring immediate deployment</purpose>
<branch-from>master</branch-from>
<merge-to>develop AND master</merge-to>
<naming>hotfix-X.Y.Z or hotfix/critical-issue-description</naming>
<indicators>
<indicator>Security vulnerability fixes</indicator>
<indicator>Critical production bugs</indicator>
<indicator>Data corruption fixes</indicator>
<indicator>Service outage resolution</indicator>
<indicator>Emergency configuration changes</indicator>
</indicators>
</hotfix>
</branch-types>
</analysis-framework>
<naming-conventions>
<feature-branches>
<format>feature/[ticket-number-]descriptive-name</format>
<examples>
<example>feature/user-authentication</example>
<example>feature/PROJ-123-shopping-cart</example>
<example>feature/api-rate-limiting</example>
<example>feature/dashboard-redesign</example>
</examples>
</feature-branches>
<release-branches>
<format>release-X.Y.Z</format>
<examples>
<example>release-1.2.0</example>
<example>release-2.1.0</example>
<example>release-1.0.0</example>
</examples>
</release-branches>
<hotfix-branches>
<format>hotfix-X.Y.Z OR hotfix/critical-description</format>
<examples>
<example>hotfix-1.2.1</example>
<example>hotfix/security-patch</example>
<example>hotfix/payment-gateway-fix</example>
<example>hotfix-2.1.1</example>
</examples>
</hotfix-branches>
</naming-conventions>
<analysis-process>
<step-1>
<title>Change Nature Analysis</title>
<description>Examine the types of files modified and the nature of changes</description>
<criteria>
<files-modified>Look at file extensions, directory structure, and purpose</files-modified>
<change-scope>Determine if changes are additive, corrective, or preparatory</change-scope>
<urgency-level>Assess if changes address critical issues or are developmental</urgency-level>
</criteria>
</step-1>
<step-2>
<title>Git Flow Classification</title>
<description>Map the changes to appropriate Git Flow branch type</description>
<decision-tree>
<question>Are these critical fixes for production issues?</question>
<if-yes>Consider hotfix branch</if-yes>
<if-no>
<question>Are these release preparation changes (version bumps, final tweaks)?</question>
<if-yes>Consider release branch</if-yes>
<if-no>Default to feature branch</if-no>
</if-no>
</decision-tree>
</step-2>
<step-3>
<title>Branch Name Generation</title>
<description>Create semantic, descriptive branch name</description>
<guidelines>
<use-kebab-case>Use lowercase with hyphens</use-kebab-case>
<be-descriptive>Name should clearly indicate the purpose</be-descriptive>
<include-context>Add ticket numbers or project context when available</include-context>
<keep-concise>Avoid overly long names</keep-concise>
</guidelines>
</step-3>
</analysis-process>
<edge-cases>
<mixed-changes>
<scenario>Changes include both features and bug fixes</scenario>
<resolution>Prioritize the most significant change type or suggest splitting into multiple branches</resolution>
</mixed-changes>
<no-changes>
<scenario>No changes detected in git status/diff</scenario>
<resolution>Inform user and suggest checking git status or making changes first</resolution>
</no-changes>
<existing-branch>
<scenario>Already on a feature/hotfix/release branch</scenario>
<resolution>Analyze if new branch is needed or if current branch is appropriate</resolution>
</existing-branch>
<conflicting-names>
<scenario>Suggested branch name already exists</scenario>
<resolution>Append incremental suffix or suggest alternative name</resolution>
</conflicting-names>
</edge-cases>
<examples>
<example-1>
<scenario>Added new user registration API endpoint</scenario>
<analysis>New functionality, additive changes, not critical</analysis>
<branch-type>feature</branch-type>
<branch-name>feature/user-registration-api</branch-name>
<command>git checkout -b feature/user-registration-api develop</command>
</example-1>
<example-2>
<scenario>Fixed critical security vulnerability in authentication</scenario>
<analysis>Security fix, critical for production, immediate deployment needed</analysis>
<branch-type>hotfix</branch-type>
<branch-name>hotfix/auth-security-patch</branch-name>
<command>git checkout -b hotfix/auth-security-patch master</command>
</example-2>
<example-3>
<scenario>Updated version to 2.1.0 and finalized release notes</scenario>
<analysis>Release preparation, version bump, documentation</analysis>
<branch-type>release</branch-type>
<branch-name>release-2.1.0</branch-name>
<command>git checkout -b release-2.1.0 develop</command>
</example-3>
<example-4>
<scenario>Improved database query performance and updated caching</scenario>
<analysis>Performance improvement, non-critical enhancement</analysis>
<branch-type>feature</branch-type>
<branch-name>feature/database-performance-optimization</branch-name>
<command>git checkout -b feature/database-performance-optimization develop</command>
</example-4>
</examples>
<validation>
<pre-analysis>
<check>Repository is in a clean state (no uncommitted changes that would conflict)</check>
<check>Current branch is appropriate starting point (develop for features/releases, master for hotfixes)</check>
<check>Remote repository is up to date</check>
</pre-analysis>
<analysis-quality>
<check>Change analysis covers all modified files</check>
<check>Branch type selection follows Git Flow principles</check>
<check>Branch name is semantic and follows conventions</check>
<check>Edge cases are considered and handled</check>
</analysis-quality>
<execution-safety>
<check>Target branch (develop/master) exists and is accessible</check>
<check>Proposed branch name doesn't conflict with existing branches</check>
<check>User has appropriate permissions to create branches</check>
</execution-safety>
</validation>
<execution-protocol>
<analysis-summary>
<git-status>Output of git status command</git-status>
<git-diff>Relevant portions of git diff output</git-diff>
<change-analysis>Detailed analysis of what changes represent</change-analysis>
<branch-decision>Explanation of why specific branch type was chosen</branch-decision>
</analysis-summary>
<branch-creation>
<command>git checkout -b [branch-name] [source-branch]</command>
<confirmation>Verify branch creation and current branch status</confirmation>
<next-steps>Provide guidance on next actions (commit changes, push branch, etc.)</next-steps>
</branch-creation>
<fallback-options>
<alternative-names>Suggest 2-3 alternative branch names if primary suggestion isn't suitable</alternative-names>
<manual-override>Allow user to specify different branch type if analysis seems incorrect</manual-override>
</fallback-options>
</execution-protocol>
<gitflow-reference>
<main-branches>
<master>Production-ready code, every commit is a release</master>
<develop>Integration branch for features, latest development changes</develop>
</main-branches>
<supporting-branches>
<feature>Branch from develop, merge back to develop</feature>
<release>Branch from develop, merge to both develop and master</release>
<hotfix>Branch from master, merge to both develop and master</hotfix>
</supporting-branches>
<merge-strategy>
<flag>Always use --no-ff flag to preserve branch history</flag>
<tagging>Tag releases on master branch</tagging>
<cleanup>Delete branches after successful merge</cleanup>
</merge-strategy>
</gitflow-reference>
Weekly Installs
7.5K
Repository
GitHub Stars
26.9K
First Seen
Feb 25, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykFail
Installed on
codex7.4K
gemini-cli7.4K
opencode7.3K
cursor7.3K
github-copilot7.3K
amp7.3K
React 组合模式指南:Vercel 组件架构最佳实践,提升代码可维护性
102,200 周安装