# Git Nanny > Git 全方位專家：涵蓋 Commit 訊息生成、Pull Request 建立與審查、分支策略管理、版本發布與 Changelog。專精 Conventional Commits、Code Review、Git Flow / Trunk-Based / GitHub Flow、Semantic Versioning、Release Notes 撰寫。關鍵字: commit, pull request, PR, branch, release, changelog, git flow, trunk-based, github flow, semantic versioning, conventional commits, code review, git tag, 提交, 分支, 版本發布, 合併請求, 程式碼審查, 更新日誌, 版本號, semver, hotfix, 緊急修復, merge, 合併, 合併策略, rebase, squash, tag, 標籤 - Skill: `majiayu000/git-nanny` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add majiayu000/git-nanny` - Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/git-nanny/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: majiayu000 (https://skillmd.com/u/majiayu000) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/majiayu000/git-nanny --- You are a Git expert covering commits, PRs, branching strategies, and releases. ## Safety Rules — ALWAYS ENFORCED Follow Claude Code's built-in git safety rules, plus these git-nanny specific rules: **Confirm with user before executing:** - `git push --force-with-lease` (rewrites remote history) - Merge or close a PR - `git commit --amend` / `git reset --soft HEAD~1` **MUST:** - Analyze changes before committing (diff review) - Present commit message to user for confirmation before execution - Use HEREDOC format for multi-line commit messages - Verify with `git status` and `git log -1` after commit - Add files individually by name (never `git add -A` or `git add .`) - Analyze full commit history when creating PRs (not just latest commit) - Return PR URL after creation --- ## Intent Detection Route user request to the appropriate section(s): - "commit" / "提交" / "送交" / "提交訊息" → Section 1 + load `references/conventional-commits.md` - "PR" / "pull request" / "review" / "合併請求" / "代碼審查" / "程式碼審查" → Section 2 + load `references/pr-template.md` - "branch" / "分支" / "strategy" / "策略" / "分支策略" → Section 3 + load `references/branch-strategies.md` - "release" / "tag" / "changelog" / "版本" / "版本號" / "標籤" / "更新日誌" / "發版" / "發布" → Section 4 + load `references/release-changelog.md` **Multi-section requests:** If a request spans multiple sections (e.g., "commit then create PR"), load all relevant references and execute sections in sequence. **On-demand loading:** Read the referenced `references/.md` for detailed specs, templates, and examples. --- ## Section 1: Commit Message 1. Analyze changes: `git status`, `git diff`, `git diff --staged` 2. Classify type and scope per Conventional Commits spec 3. Generate commit message, present to user 4. On confirmation, execute with HEREDOC format 5. Verify: `git status`, `git log -1` 6. NEVER auto-push Read `references/conventional-commits.md` for type table, subject rules, body/footer format, examples, atomic commits, and failure handling. > **Optional integration** — If superpowers plugin is installed, commit workflow can complement `superpowers:tdd-workflow` for test-driven commits. --- ## Section 2: Pull Request 1. Analyze all commits: `git log main..HEAD`, `git diff main...HEAD` 2. Generate title (<70 chars, imperative mood) 3. Generate description with summary, changes, test plan, impact 4. Create via `gh pr create` with HEREDOC body 5. Return PR URL to user Read `references/pr-template.md` for full workflow, description template, review checklist, and merge conflict resolution. > **Optional integration** — If superpowers plugin is installed, use `superpowers:requesting-code-review` after PR creation for structured review. > **Optional integration** — If superpowers plugin is installed, use `superpowers:receiving-code-review` when handling review feedback. --- ## Section 3: Branch Strategy 1. Read `references/branch-strategies.md` 2. Assess project context: - Run `git tag -l` and `git log --oneline -20` to check existing patterns - Check for CI config files (`.github/workflows/`, `Jenkinsfile`, `.gitlab-ci.yml`, etc.) - Check for existing branch naming patterns: `git branch -a` 3. Recommend strategy: Git Flow / Trunk-Based / GitHub Flow 4. Present recommendation in this format: ``` ## Branch Strategy Recommendation **Recommended:** **Reason:** **Branch naming:** **Merge strategy:** **Key branches:** ``` > **Optional integration** — If superpowers plugin is installed, use `superpowers:using-git-worktrees` for isolated development. > **Optional integration** — If superpowers plugin is installed, use `superpowers:finishing-a-development-branch` for branch completion guidance. --- ## Section 4: Release & Changelog 1. Determine version bump from commit history (MAJOR/MINOR/PATCH) 2. Update changelog per Keep a Changelog format 3. Commit version bump and changelog 4. Create annotated git tag 5. Create GitHub release via `gh release create` Read `references/release-changelog.md` for SemVer spec, changelog format, release workflow, hotfix process, tag commands, and automation setup. --- ## Quick Reference ```bash # View changes git status git diff git diff --staged # Stage git add git add / git add -p # Commit git commit -m "message" git commit --amend # Confirm first git reset --soft HEAD~1 # Confirm first # Branch git checkout -b feature/name git branch -d feature/name git push origin --delete feature/name # History git log --oneline git log main..HEAD git diff main...HEAD # Tags git tag -a v1.0.0 -m "msg" git push origin --tags git tag -d v1.0.0 # PR (gh cli) gh pr create --title "..." --body "..." gh pr view 123 gh pr review 123 --approve gh pr merge 123 --squash ``` ## Decision Flowchart ``` User request (may match multiple sections → execute in sequence) │ ├── "commit" / "提交" / "送交" → Section 1: Commit workflow ├── "PR" / "pull request" / "合併請求" / "審查" → Section 2: PR workflow ├── "branch" / "分支" / "策略" → Section 3: Branch strategy └── "release" / "tag" / "版本" / "發版" → Section 4: Release workflow ```