| name | git-workflow |
| description | Git version control workflows for AI coding agents. Use when tasks involve committing changes, creating branches, opening pull requests, resolving merge conflicts, writing commit messages, reviewing diffs, rebasing, stashing, cherry-picking, tagging releases, or any git-related operation. Triggers on: 'commit my changes', 'create a PR', 'push this branch', 'fix merge conflict', 'git status', 'review changes', 'squash commits', 'tag a release', 'revert a commit', or any git/GitHub/GitLab CLI workflow. |
Git Workflow Skill
Structured git workflows for AI coding agents. Follow these procedures instead of ad-hoc bash commands.
Pre-flight: Assess State
Before any git operation, gather context:
git status --short --branch
git log --oneline -5
git remote -v
Check for uncommitted changes, current branch, and remote configuration before proceeding.
Commit Workflow
1. Stage changes intentionally
Never use git add . blindly. Review what changed first:
git diff --stat
git diff
git diff --cached
Stage related changes together. Use git add -p for partial staging when a file contains unrelated changes.
2. Write Conventional Commits
Follow Conventional Commits format:
<type>(<scope>): <short summary>
<optional body — explain WHY, not WHAT>
<optional footer — references, breaking changes>
Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore
Examples:
feat(auth): add OAuth2 token refresh with exponential backoff
fix(parser): handle nested quotes in CSV fields
docs(api): add rate limiting section to REST reference
refactor(db): extract connection pooling into shared module
test(auth): add integration tests for token expiry edge cases
Rules:
- Subject line ≤ 72 characters, imperative mood ("add" not "added")
- Scope is optional but preferred for non-trivial repos
- Body wraps at 72 characters, separated by blank line
- Reference issues with
Closes #123 or Refs #456
3. Commit command
git commit -m "type(scope): summary" -m "Optional body explaining why."
For multi-line messages, use a temp file:
cat > /tmp/commit-msg.txt << 'EOF'
feat(session): add token usage and cost tracking
Track per-turn and cumulative token usage with estimated costs.
Supports budget alerts (warn + hard-stop thresholds) and
per-model cost breakdown.
Closes
EOF
git commit -F /tmp/commit-msg.txt
Branch Workflow
Naming convention
<type>/<short-description>
Examples: feat/cost-tracking, fix/oauth-refresh, docs/api-reference, refactor/db-pooling
Create and switch
git checkout -b feat/my-feature
git checkout -b feat/my-feature origin/main
Keep branch updated
git fetch origin
git rebase origin/main
git merge origin/main
If rebase conflicts arise, resolve each file, then:
git add <resolved-file>
git rebase --continue
To abort a bad rebase: git rebase --abort
Pull Request Workflow
Pre-PR checklist
- Ensure tests pass locally
- Ensure branch is up-to-date with target
- Review own diff:
git diff origin/main...HEAD --stat
Using GitHub CLI (gh)
gh pr create --title "feat(scope): summary" \
--body "## What\nDescription of changes.\n\n## Why\nMotivation.\n\n## Testing\nHow it was tested." \
--base main
gh pr create --draft --title "wip: exploration" --body "Early draft."
gh pr list
gh pr view <number>
gh pr merge <number> --squash --delete-branch
PR description template
## What
Brief description of the change.
## Why
Motivation and context.
## How
Implementation approach (optional, for complex changes).
## Testing
- [ ] Unit tests added/updated
- [ ] Manual testing performed
- [ ] CI passes
## Related
Closes #<issue>
Merge Conflict Resolution
Identify conflicts
git status
git diff --name-only --diff-filter=U
Resolution strategy
- Open each conflicted file
- Look for conflict markers:
<<<<<<<, =======, >>>>>>>
- Decide: keep ours, keep theirs, or merge manually
- Remove ALL conflict markers
- Stage resolved files:
git add <file>
- Continue the operation:
- Merge:
git commit (auto-generated message is fine)
- Rebase:
git rebase --continue
- Cherry-pick:
git cherry-pick --continue
Quick resolution commands
git checkout --ours <file>
git checkout --theirs <file>
Stash Workflow
Save work-in-progress without committing:
git stash push -m "wip: description"
git stash list
git stash pop
git stash apply stash@{1}
git stash drop stash@{0}
History Management
Interactive rebase (squash, reword, reorder)
git rebase -i HEAD~3
git rebase -i origin/main
In the editor: pick, squash (or s), reword (or r), drop (or d), edit (or e)
Undo operations
git revert <sha>
git reset --soft HEAD~1
git reset --mixed HEAD~1
git reset --hard HEAD~1
Prefer git revert on shared branches. Use git reset only on local/personal branches.
Cherry-pick
git cherry-pick <sha>
git cherry-pick <sha1> <sha2>
git cherry-pick <sha> --no-commit
Tagging Releases
git tag -a v1.2.0 -m "Release v1.2.0: cost tracking feature"
git push origin v1.2.0
git push origin --tags
Use semantic versioning: vMAJOR.MINOR.PATCH
Safety Rules
- Never force-push shared branches (
main, develop, release/*)
- Never
git reset --hard on shared branches — use git revert
- Always fetch before rebase —
git fetch origin && git rebase origin/main
- Check branch before destructive ops —
git branch --show-current
- Back up before risky operations —
git stash or create a temp branch
- When unsure, ask the user before: force-pushing, resetting, or deleting branches
Git Configuration Tips
git config --global init.defaultBranch main
git config --global pull.rebase true
git config --global rerere.enabled true
git config --global core.autocrlf input