| name | git-github |
| version | 1.0.0 |
| description | Complete Git and GitHub workflow automation. Clone repos, manage branches, create commits with conventional messages, open pull requests, manage issues, and publish releases. Use this skill when the user needs to: commit code, open a PR, manage branches, create releases, work with GitHub issues, review code, or any git/GitHub operation. Also trigger for "git", "github", "commit", "pull request", "PR", "branch", "merge", "release", or "repository."
|
| author | G-HunterAi |
| license | MIT |
| tags | ["git","github","version-control","pr","code-review","releases"] |
| platforms | ["all"] |
| category | tooling |
| metadata | {"clawdbot":{"emoji":"🔀","requires":{"bins":["git","gh"]}}} |
git-github Skill
Overview
Automate Git and GitHub workflows with safety guardrails. This skill handles version control operations, pull requests, issue tracking, and release publishing. Perfect for: committing code, managing branches, opening PRs, code review, working with issues, and publishing releases.
When to Use This Skill
Use git-github when:
- Cloning or managing repositories
- Creating or switching branches
- Committing code with conventional messages
- Opening, reviewing, or merging pull requests
- Creating or managing GitHub issues
- Publishing releases with semantic versioning
- Working with tags and release notes
- Performing code reviews
- Managing branch protection rules
- Syncing with remote repositories
Do NOT use for:
- CI/CD pipeline configuration (use dedicated CI tools: GitHub Actions, GitLab CI, Jenkins)
- Code deployment beyond tagging (use deployment tools: Kubernetes, Terraform, Ansible)
- Project management beyond GitHub issues (use mission-control, Asana, Linear)
- Repository creation from scratch (use web UI for initial setup)
Prerequisites
- Git 2.30 or newer:
git --version
- GitHub CLI (gh) 2.0 or newer:
gh --version
- Authenticated GitHub access: Run
gh auth login if needed
- Git configured:
git config --global user.name and git config --global user.email
Verify setup:
git --version && gh --version && gh auth status
Quick Start
Basic Workflow: Clone → Branch → Commit → Push → PR
gh repo clone owner/repo-name
git checkout -b feature/my-feature
git add .
git commit -m "feat: add new feature"
git push -u origin feature/my-feature
gh pr create --title "Add new feature" --body "Detailed description"
gh pr merge <pr-number> --merge
Core Concepts
Conventional Commits
Follow the Conventional Commits specification for clear, semantic commit messages:
<type>(<scope>): <subject>
<body>
<footer>
Types:
feat: New featurefix: Bug fixchore: Build, dependencies, toolingdocs: Documentation updatesrefactor: Code refactoring without feature changetest: Test additions or updatesperf: Performance improvementsstyle: Code style (formatting, missing semicolons, etc.)ci: CI/CD configurationrevert: Revert previous commit
Examples:
feat(auth): add two-factor authentication
fix(api): handle null response in error handler
docs: update README with setup instructions
chore(deps): upgrade typescript to 5.0
Branch Naming Conventions
Organize branches by type and purpose:
feature/user-authentication — New featuresbugfix/login-validation — Bug fixeshotfix/critical-security-issue — Production fixesrelease/v1.2.0 — Release preparationchore/update-dependencies — Maintenance
Pull Request Workflow
- Draft — PR created, work in progress
- Review — Request reviewers, address feedback
- Approve — Reviewers approve changes
- Merge — Merge to main/master
- Close — PR closed after merge
Merge strategies:
- Merge commit — Preserves full history
- Squash merge — Single commit, clean history
- Rebase merge — Linear history
Semantic Versioning (Releases)
Follow SemVer: MAJOR.MINOR.PATCH
- MAJOR — Breaking changes
- MINOR — Backward-compatible features
- PATCH — Bug fixes
Example: v1.2.3 → v1.3.0 (new minor feature)
Core Usage Examples
Example 1: Create Feature Branch and Commit
git checkout main
git pull origin main
git checkout -b feature/dark-mode
echo "body { theme: dark; }" >> styles.css
git diff
git add styles.css
git commit -m "feat(ui): add dark mode toggle"
git push -u origin feature/dark-mode
Example 2: Open a Pull Request
gh pr create \
--title "Add dark mode support" \
--body "Implements user preference toggle for light/dark theme" \
--draft
gh pr ready <pr-number>
gh pr edit <pr-number> --add-reviewer alice,bob
gh pr view <pr-number>
Example 3: List and Manage Issues
gh issue list --state open
gh issue list --assignee @me
gh issue create \
--title "Fix navigation menu on mobile" \
--body "Navigation doesn't collapse on small screens" \
--label "bug,mobile"
gh issue edit <issue-number> --add-label "high-priority"
gh issue close <issue-number>
Example 4: Create GitHub Release with Changelog
git tag -a v1.2.0 -m "Release version 1.2.0"
git push origin v1.2.0
gh release create v1.2.0 \
--title "Version 1.2.0" \
--notes "
## Features
- Add dark mode support
- Improve performance
## Bug Fixes
- Fix navigation collapse on mobile
## Breaking Changes
- Remove deprecated API endpoint
"
gh release list
gh release view v1.2.0
Example 5: Review and Merge Pull Request
gh pr checkout <pr-number>
git diff main
gh pr merge <pr-number> --squash
gh pr merge <pr-number> --merge
git push origin --delete feature/branch-name
git branch -d feature/branch-name
Example 6: Squash Merge for Clean History
git log main..HEAD --oneline
git checkout main
git pull origin main
git merge --squash feature/my-feature
git commit -m "feat: implement complex feature"
git push origin main
git branch -d feature/my-feature
Safety Rules
🛑 Destructive Operations Require Explicit Confirmation
-
Never force push to main/master without explicit user confirmation
git push --force-with-lease only after user approval- Always warn before rewriting history on shared branches
-
Always confirm before deleting branches
- Show which commits will be lost
- Verify no unpushed work exists
- Example:
git branch -d <branch> (protected by non-force delete)
-
Create new commits rather than amending
- Avoid
git commit --amend on shared branches
- Prevents history rewriting issues in collaborative work
-
Always show diffs before committing
- Run
git diff before git commit
- Review staged changes with
git diff --cached
-
Pull before pushing
- Always
git pull origin main before pushing
- Prevents rejected pushes due to conflicts
-
Verify branch protection rules
- Check if branch requires PR reviews before merge
- Confirm status checks pass before merging
Works Well With
- python-toolsmith — Git-tracked Python projects
- postgres-advanced — Database schema migrations via git
- mission-control — Linking issues to projects
- workflow-orchestrator — Automating CI/CD with git triggers
Error Handling
Merge Conflicts
git status
git add <resolved-file>
git commit -m "chore: resolve merge conflict"
git push origin feature/branch
Authentication Failures
gh auth login
gh auth login --with-token < ~/.ssh/github_token
git remote set-url origin git@github.com:owner/repo.git
Push Rejected (Branch Out of Date)
git pull origin main
git push origin feature/branch
Detached HEAD State
git checkout -b recovery-branch
git checkout main
Accidentally Committed to Wrong Branch
git reset HEAD~1
git checkout -b correct-branch
git commit -m "feat: message"
Verification
After operations, verify state:
git status
gh auth status
git log --oneline -5
git branch -a
References
