home / skills / cloudai-x / claude-workflow-v2 / managing-git

managing-git skill

/skills/managing-git

This skill helps you manage Git workflows, create atomic commits, handle branches, and open PRs with best practices.

npx playbooks add skill cloudai-x/claude-workflow-v2 --skill managing-git

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.5 KB
---
name: managing-git
description: Manages Git workflows including branching, commits, and pull requests. Use when working with Git, creating commits, opening PRs, managing branches, resolving conflicts, or when asked about version control best practices.
---

# Managing Git

## Feature Development Workflow

Copy this checklist and track progress:

```
Feature Development Progress:
- [ ] Step 1: Create feature branch from main
- [ ] Step 2: Make changes with atomic commits
- [ ] Step 3: Rebase on latest main
- [ ] Step 4: Push and create PR
- [ ] Step 5: Address review feedback
- [ ] Step 6: Merge after approval
```

## Branching Strategies

### GitHub Flow (Recommended for most projects)
```
main ──●────●────●────●────●── (always deployable)
        \          /
feature  └──●──●──┘
```
- `main` is always deployable
- Feature branches from main
- PR + review + merge
- Deploy after merge

### Git Flow (For release-based projects)
```
main     ──●─────────────●────── (releases only)
            \           /
release      └────●────┘
                 /
develop  ──●──●────●──●──●──
            \     /
feature      └──●┘
```

## Commit Conventions

### Conventional Commits Format
```
<type>(<scope>): <description>

[optional body]

[optional footer(s)]
```

### Types
| Type | Description |
|------|-------------|
| `feat` | New feature |
| `fix` | Bug fix |
| `docs` | Documentation only |
| `style` | Formatting, no logic change |
| `refactor` | Code change that neither fixes bug nor adds feature |
| `perf` | Performance improvement |
| `test` | Adding/updating tests |
| `chore` | Build process, dependencies |
| `ci` | CI configuration |

### Examples
```bash
feat(auth): add OAuth2 login support

Implements Google and GitHub OAuth providers.
Closes #123

BREAKING CHANGE: Session tokens now expire after 24h
```

```bash
fix(api): handle null response from payment gateway

Previously caused 500 error when gateway returned null.
Now returns appropriate error message to user.
```

## Branch Naming
```
<type>/<ticket-id>-<short-description>

# Examples
feature/AUTH-123-oauth-login
fix/BUG-456-null-pointer
chore/TECH-789-upgrade-deps
```

## Pull Request Workflow

Copy this checklist when creating PRs:

```
PR Checklist:
- [ ] Code follows project conventions
- [ ] Tests added/updated for changes
- [ ] All tests pass locally
- [ ] No merge conflicts with main
- [ ] Documentation updated if needed
- [ ] No security vulnerabilities introduced
- [ ] PR description explains the "why"
```

### PR Template
```markdown
## Summary
[Brief description of changes]

## Changes
- [Change 1]
- [Change 2]

## Testing
- [ ] Unit tests added/updated
- [ ] Manual testing performed
- [ ] E2E tests pass

## Screenshots (if UI changes)
[Before/After screenshots]
```

### PR Size Guidelines
| Size | Lines Changed | Review Guidance |
|------|---------------|-----------------|
| XS | < 50 | Quick review |
| S | 50-200 | Standard review |
| M | 200-500 | Thorough review |
| L | 500+ | Split if possible |

## Common Git Commands

### Daily Workflow
```bash
# Start new feature
git checkout main
git pull
git checkout -b feature/TICKET-123-description

# Commit changes
git add -p  # Stage interactively
git commit -m "feat: description"

# Keep up with main
git fetch origin main
git rebase origin/main

# Push and create PR
git push -u origin HEAD
```

### Fixing Mistakes
```bash
# Amend last commit (before push)
git commit --amend

# Undo last commit (keep changes)
git reset --soft HEAD~1

# Undo last commit (discard changes)
git reset --hard HEAD~1

# Revert a pushed commit
git revert <commit-hash>

# Interactive rebase to clean up
git rebase -i HEAD~3
```

### Advanced Operations
```bash
# Cherry-pick specific commit
git cherry-pick <commit-hash>

# Find which commit broke something
git bisect start
git bisect bad HEAD
git bisect good <known-good-commit>

# Stash with message
git stash push -m "WIP: feature description"
git stash list
git stash pop
```

## Commit Validation

Before pushing, validate commits:

```
Commit Validation:
- [ ] Each commit has a clear, descriptive message
- [ ] Commit type matches the change (feat, fix, etc.)
- [ ] No WIP or temporary commits
- [ ] No secrets or credentials committed
- [ ] Changes are atomic (one logical change per commit)
```

If validation fails, use `git rebase -i` to clean up commit history before pushing.

Overview

This skill manages Git workflows including branching, commits, pull requests, and common recovery actions. It provides practical checklists, branch naming conventions, commit message formats, and everyday Git commands to keep history clean and reviews fast. Use it to enforce consistent version control practices across feature work and releases.

How this skill works

The skill inspects workflow needs and recommends actions: create feature branches, craft atomic commits, rebase on main, and open PRs with a checklist. It suggests branching strategies (GitHub Flow vs Git Flow), conventional commit formats, and PR templates. It also provides common commands for daily work and fixes like amend, reset, revert, and interactive rebase.

When to use it

  • Starting a new feature or bug fix branch
  • Preparing commits and cleaning history before pushing
  • Opening a pull request or preparing a PR description
  • Resolving merge conflicts or rebasing onto main
  • Choosing a branching strategy for a project
  • Recovering from mistaken commits or broken builds

Best practices

  • Branch from main for small, deployable changes (GitHub Flow) or use develop/release branches for release-driven projects (Git Flow)
  • Use Conventional Commits: type(scope): short description, include body and footers when needed
  • Make atomic commits: one logical change per commit and keep messages descriptive
  • Rebase on the latest main before pushing to reduce merge conflicts and keep history linear
  • Run commit validation: clear messages, correct type, no secrets, and no WIP commits
  • Keep PRs appropriately sized; split very large changes and include tests and a clear why in the description

Example use cases

  • Create a feature branch, make several small commits, rebase on main, squash with interactive rebase, and open a PR
  • Follow PR checklist and template to ensure tests and documentation are included before merge
  • Recover from a bad pushed commit by reverting or using reset locally followed by force-push with caution
  • Use git bisect to find failing commits during regression testing
  • Cherry-pick a bug fix commit into a release branch without merging all feature work

FAQ

What commit type should I use for a test-only change?

Use test(scope): description for changes that only add or update tests.

When should I rebase vs merge from main?

Rebase to keep a linear history and resolve conflicts locally before PR. Merge is fine for preserving historical merge context or when following a non-linear workflow.