git-flow-branch-creator

✓ Official★ 36,200

by github · part of github/awesome-copilot

Analyzes git changes and creates semantic Git Flow branches automatically based on change type. Inspects staged and unstaged changes via git status and git diff to determine branch category: feature, release, or hotfix Generates semantic branch names following Git Flow conventions (e.g., feature/user-auth , release-1.2.0 , hotfix/security-patch ) Branches from the correct source ( develop for features and releases, master for hotfixes) and creates the branch in one command Handles edge cases...

🔥🔥🔥✓ VerifiedFreeQuick setup

#automation #payments #database #devops #git #security

🧩 One of 7 skills in the github/awesome-copilot package — works on its own, and pairs well with its siblings.

Inspect the full instructions your agent will receiveExpand

This is the exact playbook injected into your agent when the skill activates — shown here so you can audit it before installing. You don't need to read it to use the skill.

by github

Instructions

Copy & paste — that's it

 
 Git Flow Branch Creator 
 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. 
 
 Just run this prompt and Copilot will analyze your changes and create the appropriate Git Flow branch for you.

Workflow

Follow these steps:

Run git status to review the current repository state and changed files.
Run git diff (for unstaged changes) or git diff --cached (for staged changes) to analyze the nature of changes.
Analyze the changes using the Git Flow Branch Analysis Framework below.
Determine the appropriate branch type based on the analysis.
Generate a semantic branch name following Git Flow conventions.
Create the branch and switch to it automatically.
Provide a summary of the analysis and next steps.

Git Flow Branch Analysis Framework

Copy & paste — that's it

 
 
 
 New features, enhancements, non-critical improvements 
 develop 
 develop 
 feature/descriptive-name or feature/ticket-number-description 
 
 New functionality being added 
 UI/UX improvements 
 New API endpoints or methods 
 Database schema additions (non-breaking) 
 New configuration options 
 Performance improvements (non-critical) 
 
 

 
 Release preparation, version bumps, final testing 
 develop 
 develop AND master 
 release-X.Y.Z 
 
 Version number changes 
 Build configuration updates 
 Documentation finalization 
 Minor bug fixes before release 
 Release notes updates 
 Dependency version locks 
 
 

 
 Critical production bug fixes requiring immediate deployment 
 master 
 develop AND master 
 hotfix-X.Y.Z or hotfix/critical-issue-description 
 
 Security vulnerability fixes 
 Critical production bugs 
 Data corruption fixes 
 Service outage resolution 
 Emergency configuration changes

Branch Naming Conventions

Copy & paste — that's it

 
 
 feature/[ticket-number-]descriptive-name 
 
 feature/user-authentication 
 feature/PROJ-123-shopping-cart 
 feature/api-rate-limiting 
 feature/dashboard-redesign 
 
 

 
 release-X.Y.Z 
 
 release-1.2.0 
 release-2.1.0 
 release-1.0.0 
 
 

 
 hotfix-X.Y.Z OR hotfix/critical-description 
 
 hotfix-1.2.1 
 hotfix/security-patch 
 hotfix/payment-gateway-fix 
 hotfix-2.1.1

Analysis Process

Copy & paste — that's it

 
 
 Change Nature Analysis 
 Examine the types of files modified and the nature of changes 
 
 Look at file extensions, directory structure, and purpose 
 Determine if changes are additive, corrective, or preparatory 
 Assess if changes address critical issues or are developmental 
 
 

 
 Git Flow Classification 
 Map the changes to appropriate Git Flow branch type 
 
 Are these critical fixes for production issues? 
 Consider hotfix branch 
 
 Are these release preparation changes (version bumps, final tweaks)? 
 Consider release branch 
 Default to feature branch 
 
 
 

 
 Branch Name Generation 
 Create semantic, descriptive branch name 
 
 Use lowercase with hyphens 
 Name should clearly indicate the purpose 
 Add ticket numbers or project context when available 
 Avoid overly long names

Edge Cases and Validation

Copy & paste — that's it

 
 
 Changes include both features and bug fixes 
 Prioritize the most significant change type or suggest splitting into multiple branches 
 

 
 No changes detected in git status/diff 
 Inform user and suggest checking git status or making changes first 
 

 
 Already on a feature/hotfix/release branch 
 Analyze if new branch is needed or if current branch is appropriate 
 

 
 Suggested branch name already exists 
 Append incremental suffix or suggest alternative name

Examples

Copy & paste — that's it

 
 
 Added new user registration API endpoint 
 New functionality, additive changes, not critical 
 feature 
 feature/user-registration-api 
 git checkout -b feature/user-registration-api develop 
 

 
 Fixed critical security vulnerability in authentication 
 Security fix, critical for production, immediate deployment needed 
 hotfix 
 hotfix/auth-security-patch 
 git checkout -b hotfix/auth-security-patch master 
 

 
 Updated version to 2.1.0 and finalized release notes 
 Release preparation, version bump, documentation 
 release 
 release-2.1.0 
 git checkout -b release-2.1.0 develop 
 

 
 Improved database query performance and updated caching 
 Performance improvement, non-critical enhancement 
 feature 
 feature/database-performance-optimization 
 git checkout -b feature/database-performance-optimization develop

Validation Checklist

Copy & paste — that's it

 
 
 Repository is in a clean state (no uncommitted changes that would conflict) 
 Current branch is appropriate starting point (develop for features/releases, master for hotfixes) 
 Remote repository is up to date 
 

 
 Change analysis covers all modified files 
 Branch type selection follows Git Flow principles 
 Branch name is semantic and follows conventions 
 Edge cases are considered and handled 
 

 
 Target branch (develop/master) exists and is accessible 
 Proposed branch name doesn't conflict with existing branches 
 User has appropriate permissions to create branches

Final Execution

Copy & paste — that's it

 
 
 Output of git status command 
 Relevant portions of git diff output 
 Detailed analysis of what changes represent 
 Explanation of why specific branch type was chosen 
 

 
 git checkout -b [branch-name] [source-branch] 
 Verify branch creation and current branch status 
 Provide guidance on next actions (commit changes, push branch, etc.) 
 

 
 Suggest 2-3 alternative branch names if primary suggestion isn't suitable 
 Allow user to specify different branch type if analysis seems incorrect

Git Flow Reference

Copy & paste — that's it

 
 
 Production-ready code, every commit is a release 
 Integration branch for features, latest development changes 
 

 
 Branch from develop, merge back to develop 
 Branch from develop, merge to both develop and master 
 Branch from master, merge to both develop and master 
 

 
 Always use --no-ff flag to preserve branch history 
 Tag releases on master branch 
 Delete branches after successful merge