| name | git-workflow |
| description | Git operations, branching strategies, conflict resolution, commit conventions, and repository maintenance |
| layer | utility |
| category | tooling |
| triggers | ["git workflow","branching strategy","merge conflict","rebase","commit message","git history","cherry pick","release branch"] |
| inputs | [{"operation":"branch | merge | rebase | cherry-pick | bisect | stash | tag | release"},{"context":"Current repository state and branch information"},{"strategy":"trunk-based | gitflow | github-flow"}] |
| outputs | [{"commands":"Git commands to execute in order"},{"explanation":"Why these commands and in this order"},{"warnings":"Potential risks or data loss scenarios"},{"rollback":"How to undo the operation if needed"}] |
| linksTo | ["error-handling","logging"] |
| linkedFrom | ["orchestrator","planner"] |
| preferredNextSkills | ["error-handling","logging"] |
| fallbackSkills | ["sequential-thinking"] |
| riskLevel | medium |
| memoryReadPolicy | selective |
| memoryWritePolicy | selective |
| sideEffects | [{"git_state":"Modifies git history, branches, and working tree"}] |
Git Workflow
Purpose
This skill provides expert guidance on Git operations from basic branching to complex history rewriting. It prioritizes safe, reversible operations and always includes rollback instructions. It covers branching strategies, commit conventions, conflict resolution, release management, and repository maintenance.
Key Concepts
Safety Principles
1. NEVER force push to shared branches (main, develop, release/*)
2. ALWAYS create a backup branch before destructive operations
3. PREFER merge over rebase for shared branches
4. PREFER rebase for local/feature branches before merging
5. ALWAYS verify with `git status` and `git log` before and after operations
6. NEVER skip pre-commit hooks (--no-verify) unless explicitly instructed
7. NEVER amend commits that have been pushed to shared branches
Branching Strategies
Trunk-Based Development (Recommended for small teams)
main ─────────────────────────────────────────────
│ │ │ │
└─ feat/a ┘ └─ feat/b ┘ └─ fix/c ┘
(short-lived, < 2 days)
RULES:
- Feature branches live < 2 days
- Merge to main via PR with CI checks
- Release from main (tag-based)
- Feature flags for incomplete work
- No long-lived branches
GitHub Flow (Good for continuous deployment)
main ──────────────────────────────────────────
│ │ │
└─ feature/auth ┘ └─ feature/orders ┘
(PR-based merge) (PR-based merge)
RULES:
- main is always deployable
- Branch from main, PR back to main
- Deploy immediately after merge
- No release branches
Git Flow (For versioned releases)
main ─────────────────────────────── v1.0 ─── v2.0
│ │ │
develop ──────────────────────────────────────────
│ │ │ │
└─ feat/a ┘ └─ feat/b ┘ └─ release/1.0 ┘
│
└─ hotfix/1.0.1 ┘
RULES:
- main: production releases only (tagged)
- develop: integration branch
- feature/*: branch from develop, merge to develop
- release/*: branch from develop, merge to main + develop
- hotfix/*: branch from main, merge to main + develop
Commit Message Convention (Conventional Commits)
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Types:
| Type | Use When |
|---|
feat | New feature for the user |
|