菜单
Initialize git-flow, manage feature/release/hotfix branches, and coordinate multi-component releases. Use when setting up branching strategy, starting/finishing branches, or releasing with semantic versioning. Integrates with release-process skill.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Resolve git rebase conflicts one block at a time with verification. Use when rebasing, resolving merge conflicts, or continuing a rebase. Works with git rerere. Always keeps HEAD by default, verifies with grep, never uses bulk operations. Delegates file edits to subagents.
Manage git-flow branching workflows. Use when working with feature branches, release branches, hotfixes, or configuring branching strategy. Supports Classic GitFlow, GitHub Flow, GitLab Flow, and custom configurations.
Plan and execute releases with semantic versioning and bracket-based freezing. Use when: "how do I release", "bump the version", "write the changelog", "what version comes next", "release the plugin", or managing scope creep in monorepos. Prevents version thrashing; supports single projects, monorepos, and multi-component systems.
| name | git-flow |
| description | Initialize git-flow, manage feature/release/hotfix branches, and coordinate multi-component releases. Use when setting up branching strategy, starting/finishing branches, or releasing with semantic versioning. Integrates with release-process skill. |
| version | 1.0.0 |
| allowed-tools | Bash(git:*),Read,Write |
Git-flow is a structured branching model that organizes parallel development with dedicated branch types. This skill guides setup, branch operations, and integration with semantic versioning.
Branch types:
main — Production, always deployabledevelop — Integration, pre-releasefeature/* — New features (from develop)release/* — Release prep (version bump)hotfix/* — Production fixes (from main)When to use: Team with multiple concurrent features, explicit dev/prod separation, or semantic versioning.
macOS (Homebrew):
brew install git-flow
Linux (apt):
sudo apt-get install git-flow
Windows (Git Bash):
# Option A: Download installer from github.com/nvie/gitflow
# Option B: Via Chocolatey
choco install gitflow
Verify installation:
git flow version
git flow init
You'll be prompted to confirm branch names:
main)develop)feature/)release/)hotfix/)Press Enter to accept defaults unless your team has different conventions.
# Check branches were created
git branch -a
# Expected output:
# * develop
# main
git flow feature start my-feature-name
This creates and checks out feature/my-feature-name from develop.
What happens:
developConvention: Use lowercase hyphen-separated names: feature/user-authentication, feature/payment-integration
git flow feature finish my-feature-name
This:
feature/my-feature-name into developdevelopBefore finishing:
git push origin feature/my-feature-nameUse this when you're ready to prepare a release version.
git flow release start 1.2.0
This creates release/1.2.0 from develop.
In the release branch:
Coordinate with release-process skill:
release-process skill first to determine version (MAJOR.MINOR.PATCH)git flow release start X.Y.Zgit flow release finish 1.2.0
This:
release/1.2.0 into mainmain with version number (v1.2.0)release/1.2.0 back into develop (keeps versions in sync)developAfter finishing:
git push origin main develop --tagsmain branch to productionUse for urgent production bugs.
git flow hotfix start 1.2.1
This creates hotfix/1.2.1 from main (not develop—critical!).
In the hotfix branch:
Version rule: Hotfix version = last release version + PATCH bump
git flow hotfix finish 1.2.1
This:
hotfix/1.2.1 into mainmain with version (v1.2.1)hotfix/1.2.1 back into develop (keeps versions in sync)After finishing:
git push origin main develop --tagsmain immediately to productiondevelop for next releaseFor projects with multiple components (plugin + skills, monorepos):
Rule: Parent version ≥ max(child versions)
See references/multi-component-coordination.md for detailed release strategies, version coordination matrices, and multi-component examples.
Let your team review the branch before merging:
git push origin feature/my-feature-name
# Create pull request on GitHub
# After approval, run:
git flow feature finish my-feature-name
git flow feature delete my-feature-name
git flow feature list # In-progress features
git flow release list # Pending releases
git flow hotfix list # Active hotfixes
# Resolve conflicts in editor
git add .
git commit -m "Resolve merge conflicts"
# Finish command will complete the merge
git flow release finish 1.2.0
If teammates updated develop while you were on a feature:
git fetch origin
git rebase origin/develop
# (Fix any conflicts, then continue work)
This skill coordinates with release-process skill for semantic versioning:
release-process skill to determine version bump (PATCH/MINOR/MAJOR)git flow release start X.Y.Z with the determined versionExample workflow:
# Step 1: Use release-process to determine version
# → Returns: "Bump to 1.3.0 (minor update)"
# Step 2: Start release with that version
git flow release start 1.3.0
# Step 3: Update version files (guided by release-process)
# → Update plugin.json, SKILL.md, etc.
# Step 4: Update CHANGELOG.md (using changelog rules)
# → Document user-facing changes
# Step 5: Finish and tag
git flow release finish 1.3.0
git push origin main develop --tags
Branch protection: Most teams protect main and develop:
Naming conventions:
feature/user-auth, feature/api-v2 (lowercase, hyphens)release/1.2.0 (semantic version)hotfix/1.2.1 (semantic version)Commit messages: Use conventional commits when working with automated changelog generation:
feat: add user authentication
fix: resolve payment processing bug
docs: update installation guide
Team communication: Announce when starting/finishing releases or hotfixes so team knows deployment is coming.
Version numbers follow semantic versioning: See release-process skill for detailed bracket rules and version decisions.