git-github
npx machina-cli add skill akaszubski/autonomous-dev/git-github --openclawGit and GitHub Workflow Skill
Comprehensive guide for Git version control and GitHub collaboration patterns.
When This Activates
- Creating commits or branches
- Opening or reviewing pull requests
- Managing GitHub issues
- Using the gh CLI
- Keywords: "git", "github", "commit", "branch", "pr", "pull request", "merge", "issue"
Conventional Commits
All commit messages follow the conventional commits specification:
<type>(<scope>): <description>
[optional body]
[optional footer(s)]
Types
| Type | When to Use |
|---|---|
feat | New feature or capability |
fix | Bug fix |
docs | Documentation only changes |
style | Formatting, missing semicolons, etc. |
refactor | Code change that neither fixes a bug nor adds a feature |
perf | Performance improvement |
test | Adding or correcting tests |
chore | Build process, auxiliary tools, or maintenance |
ci | CI/CD configuration changes |
Examples
feat(auth): add JWT token refresh endpoint
fix(api): handle null response from upstream service
docs: update API reference for v2 endpoints
refactor(db): extract query builder into separate module
test(auth): add integration tests for OAuth flow
chore: upgrade dependencies to latest versions
Breaking Changes
Use ! after type or add BREAKING CHANGE: footer:
feat(api)!: change response format from XML to JSON
Branch Naming Conventions
<type>/<issue-number>-<short-description>
Patterns
| Pattern | Example |
|---|---|
| Feature | feat/123-add-user-auth |
| Bug fix | fix/456-null-pointer-crash |
| Docs | docs/789-update-api-reference |
| Refactor | refactor/101-extract-helpers |
Rules
- Use lowercase with hyphens (no underscores or spaces)
- Include issue number when applicable
- Keep descriptions under 5 words
- Delete branches after merging
PR Workflow with gh CLI
Creating Pull Requests
# Create PR with title and body
gh pr create --title "feat: add user authentication" --body "$(cat <<'EOF'
## Summary
- Add JWT-based authentication
- Implement login/logout endpoints
## Test plan
- [ ] Unit tests for token generation
- [ ] Integration tests for auth flow
EOF
)"
# Create draft PR
gh pr create --draft --title "wip: refactor database layer"
# Create PR targeting specific base branch
gh pr create --base develop --title "feat: new feature"
Reviewing Pull Requests
# List open PRs
gh pr list
# View PR details
gh pr view 123
# Check out PR locally
gh pr checkout 123
# Approve PR
gh pr review 123 --approve
# Request changes
gh pr review 123 --request-changes --body "Please fix the error handling"
# Merge PR
gh pr merge 123 --squash --delete-branch
PR Best Practices
- Keep PRs small - Under 400 lines changed when possible
- One concern per PR - Don't mix features with refactors
- Write descriptive titles - Use conventional commit format
- Include test plan - Checklist of what to verify
- Link issues - Use "Closes #123" in body
Issue Management
Creating Issues
# Create issue with title and body
gh issue create --title "Bug: login fails on Safari" --body "Steps to reproduce..."
# Create with labels
gh issue create --title "feat: dark mode" --label "enhancement,ui"
# Create with assignee
gh issue create --title "fix: memory leak" --assignee "@me"
Issue Templates
Use labels to categorize:
| Label | Color | Purpose |
|---|---|---|
bug | red | Something broken |
enhancement | blue | New feature request |
documentation | green | Docs improvement |
good first issue | purple | Beginner friendly |
priority: high | orange | Needs immediate attention |
Linking Issues to PRs
# In PR body
Closes #123
Fixes #456
Resolves #789
Git Hooks Best Practices
Pre-commit
# Format code
black --check src/
isort --check src/
# Lint
flake8 src/
# Check for secrets
detect-secrets scan
Pre-push
# Run tests
pytest tests/ -x --timeout=60
# Type check
mypy src/
Commit-msg
# Validate conventional commit format
pattern="^(feat|fix|docs|style|refactor|perf|test|chore|ci)(\(.+\))?!?: .{1,72}"
if ! echo "$1" | grep -qE "$pattern"; then
echo "Invalid commit message format"
exit 1
fi
Common Git Operations
Stashing Changes
git stash push -m "wip: authentication changes"
git stash list
git stash pop
Interactive Rebase (cleanup before PR)
git rebase -i HEAD~3 # Squash last 3 commits
Cherry-picking
git cherry-pick abc1234 # Apply specific commit
Resolving Conflicts
git merge main # Trigger merge
# Fix conflicts in editor
git add .
git commit # Complete merge
Key Takeaways
- Conventional commits - Always use type(scope): description format
- Branch naming - type/issue-description pattern
- Small PRs - Under 400 lines, one concern each
- gh CLI - Use for all GitHub operations
- Link issues - Always connect PRs to issues
- Git hooks - Automate quality checks
- Delete merged branches - Keep repository clean
Hard Rules
FORBIDDEN:
- Force-pushing to main/master without explicit approval
- Committing secrets, API keys, or credentials (use
.envfiles) - Merge commits with failing CI checks
- PRs without linked issues or description
REQUIRED:
- All PRs MUST have a description explaining the "why"
- Branch names MUST follow
type/issue-descriptionpattern - Commits MUST use conventional commit format (
feat:,fix:,docs:, etc.) - All PRs MUST pass CI before merge
Source
git clone https://github.com/akaszubski/autonomous-dev/blob/master/plugins/autonomous-dev/skills/git-github/SKILL.mdView on GitHub Overview
This skill provides a practical guide to Git version control and GitHub collaboration patterns. It covers conventional commits, branch naming, PR workflows, and using the gh CLI to manage issues, PRs, and reviews, helping teams standardize workflows and improve collaboration.
How This Skill Works
Developers format commits using conventional types (feat, fix, docs, style, refactor, perf, test, chore, ci). Branch names follow the <type>/<issue-number>-<short-description> convention, and PRs are created, reviewed, and merged via gh CLI commands. The guide also covers creating issues, labeling, and linking them in PR bodies for traceability.
When to Use It
- When starting new work: create a feature or bug-fix branch using the conventional naming pattern.
- When opening or reviewing pull requests with teammates to ensure small, well-described changes.
- When managing GitHub issues and applying labels to group work and track progress.
- When using the gh CLI to create, list, view, review, and merge PRs or create issues.
- When enforcing a consistent commit history and handling breaking changes with conventional commits.
Quick Start
- Step 1: Write commits using conventional types (e.g., feat, fix) and a scope if relevant.
- Step 2: Create branches with the pattern <type>/<issue-number>-<short-description> and delete after merging.
- Step 3: Use gh pr create, gh pr review, and gh pr merge to manage PRs and keep the workflow centralized.
Best Practices
- Follow the conventional commits specification for all commit messages.
- Name branches lowercase, with hyphens and an included issue number when applicable.
- Keep PRs small and focused; address one concern per PR.
- Provide a clear PR description and a test plan.
- Link issues in the PR body using 'Closes #123' to ensure traceability.
Example Use Cases
- feat(auth): add JWT token refresh endpoint
- fix(api): handle null response from upstream service
- docs: update API reference for v2 endpoints
- Branch example: feat/123-add-user-auth for the new auth feature
- gh pr merge 123 --squash --delete-branch