Git Workflow Skills: Commit, Branch, and Merge Automation

Git is the backbone of modern software development, but its power comes with complexity. Commit messages drift from conventions. Branch naming becomes inconsistent. Merge conflicts multiply. The mental overhead of "proper" Git usage adds friction to the development flow.

Git workflow skills for Claude Code address this friction by encoding your team's Git conventions into automated, consistent processes. In this deep dive, we'll explore the major categories of Git skills and how they transform everyday version control operations.

The Git Workflow Challenge

Despite Git's ubiquity, teams struggle with common issues:

Commit Message Chaos: Messages range from "fixed stuff" to multi-paragraph essays. No consistent format means history is hard to parse.

Branch Proliferation: Feature branches linger. Naming is inconsistent. It's unclear what's active versus abandoned.

Merge Anxiety: Complex merges feel risky. Conflicts require mental context reconstruction.

History Hygiene: When to squash? When to rebase? When to merge? Teams apply different strategies inconsistently.

Git skills don't just automate commands; they encode decisions about how your team uses Git.

Skill Category 1: Commit Skills

The most common Git skills focus on commits; the atomic unit of change.

conventional-commit

Generates commits following the Conventional Commits standard:

# Conventional Commit

Create commits following Conventional Commits specification.

## Format

type(scope): description

[optional body]

[optional footer(s)]

## Types

- feat: New feature (MINOR version bump)
- fix: Bug fix (PATCH version bump)
- docs: Documentation only changes
- style: Code style (formatting, missing semi-colons)
- refactor: Code change that neither fixes a bug nor adds a feature
- perf: Performance improvement
- test: Adding or correcting tests
- build: Build system or external dependency changes
- ci: CI configuration changes
- chore: Other changes that don't modify src or test files
- revert: Reverts a previous commit

## Scope (optional)

Component or area affected: (auth), (api), (ui), (db)

## Breaking Changes

Add ! after type or BREAKING CHANGE: in footer:
feat(api)!: remove deprecated endpoints

## Process

1. Run `git status` to see changed files
2. Run `git diff --staged` to analyze changes
3. Determine type from nature of changes
4. Identify scope from affected area
5. Write clear, imperative description
6. Add body if explanation needed
7. Add footer for breaking changes or issue references

## Examples

feat(auth): add OAuth2 login with Google

fix(parser): handle empty input without crashing

Fixes #142

docs: update README with new API endpoints

refactor(db)!: rename user_id to account_id

BREAKING CHANGE: All queries using user_id must be updated.

What Makes It Powerful

The skill analyzes your changes and suggests appropriate types and scopes:

User: /commit

Analyzing staged changes...

Files changed:
- src/auth/oauth.ts (new file, 145 lines)
- src/auth/providers/google.ts (new file, 82 lines)
- src/routes/auth.ts (modified, +23 lines)
- package.json (modified, added @googleapis/oauth2)
- tests/auth/oauth.test.ts (new file, 67 lines)

Suggested commit:

feat(auth): add Google OAuth2 authentication

- Implement OAuth2 flow with Google provider
- Add callback route for token exchange
- Include refresh token handling
- Add unit tests for OAuth flow

Shall I create this commit? (y/n/edit)

smart-commit

Goes beyond conventional format to analyze the semantic meaning of changes:

# Smart Commit

Intelligent commit message generation with context analysis.

## Analysis Depth

### File-Level
- What files changed
- Net additions/deletions
- File types affected

### Code-Level
- Functions added/modified/removed
- Classes changed
- Imports added
- Tests added

### Semantic-Level
- Purpose of changes (feature, fix, refactor)
- Relationship between changed files
- Breaking change detection

## Output

Generates commit message that explains:
- WHAT changed (summary)
- WHY it changed (context)
- HOW it relates to other changes (connections)

## Example

Instead of: "updated user service"

Generates:

fix(users): prevent duplicate email registration

When creating a user, the system now checks for existing emails
before insertion. Previously, a duplicate key error would occur
at the database level, returning a 500 error.

Now returns 400 with message "Email already registered" if
a user with the same email exists.

Fixes #287

commit-lint

Validates commit messages against standards:

# Commit Lint

Validate commit messages before they're finalized.

## Rules

### Structure
- Header line max 72 characters
- Body wrapped at 72 characters
- Blank line between header and body

### Type
- Must be valid type (feat, fix, etc.)
- Type must be lowercase

### Scope
- Must be lowercase
- No spaces (use hyphens)
- Optional but encouraged

### Description
- Must be present
- Imperative mood ("add" not "added")
- No period at end
- Lowercase start (after type)

### Body
- Explain what and why, not how
- May include bullet points

### Footer
- Issue references: Fixes #123
- Breaking changes: BREAKING CHANGE: description

## Validation Output

✓ Type 'feat' is valid
✓ Scope 'auth' is valid
✓ Description is imperative mood
✗ Header exceeds 72 characters (84)
✗ Missing blank line before body

Suggested fix:
[reformatted message]

Skill Category 2: Branch Management

Branch skills help with the lifecycle of feature and fix branches.

branch-creator

Creates branches with consistent naming:

# Branch Creator

Create branches following team conventions.

## Naming Convention

{type}/{issue-number}-{short-description}

## Types

- feature/ - New functionality
- fix/ - Bug fixes
- hotfix/ - Production fixes
- chore/ - Maintenance tasks
- docs/ - Documentation updates
- refactor/ - Code restructuring
- test/ - Test additions

## Process

1. Get branch type from user or infer from context
2. Get issue number if applicable
3. Get short description
4. Sanitize description (lowercase, hyphens)
5. Create branch from appropriate base

## Examples

feature/142-add-oauth-login
fix/287-prevent-duplicate-emails
hotfix/301-security-patch
chore/update-dependencies
docs/api-documentation

## Integration

When creating from issue:
/branch-create #142

Fetches issue title, extracts key words, suggests branch name.

branch-cleanup

Manages branch hygiene:

# Branch Cleanup

Clean up stale and merged branches.

## Detection

### Merged Branches
Branches fully merged to main/master:
`git branch --merged main`

### Stale Branches
Branches with no commits in 30+ days:
`git for-each-ref --sort=-committerdate refs/heads/`

### Gone Branches
Local branches whose remote is deleted:
`git branch -vv | grep ': gone]'`

## Process

1. Fetch latest from remote
2. Identify candidates for cleanup
3. Present list with last commit dates
4. Confirm before deletion
5. Delete local and remote branches

## Safety

- Never delete main, master, develop, or release branches
- Require confirmation for each deletion
- Show last commit to verify branch is truly obsolete
- Offer to archive rather than delete

## Output

### Merged Branches (safe to delete)
- feature/142-oauth-login (merged 3 days ago)
- fix/287-duplicate-emails (merged 1 week ago)

### Stale Branches (no activity 30+ days)
- feature/old-experiment (last commit: 2 months ago)

### Gone Branches (remote deleted)
- feature/completed-feature

Delete these branches? (all/select/cancel)

branch-status

Provides overview of all branches:

# Branch Status

Get a clear picture of all branches and their status.

## Information Collected

For each branch:
- Last commit date
- Commits ahead/behind main
- PR status (if exists)
- CI status (if available)
- Author of last commit

## Output

### Active Development
| Branch | Last Commit | Ahead | Behind | PR | CI |
|--------|-------------|-------|--------|-----|-----|
| feature/new-api | 2 hours ago | 12 | 3 | #456 | ✓ |
| fix/login-bug | 1 day ago | 3 | 0 | #457 | ✗ |

### Needs Attention
| Branch | Issue |
|--------|-------|
| feature/old-work | 45 commits behind, no PR |
| fix/stale | No activity 3 weeks |

### Ready to Merge
| Branch | PR | Approvals |
|--------|-----|-----------|
| feature/complete | #455 | 2/2 |

### Recommendations
- Rebase feature/new-api (3 commits behind)
- Review or close feature/old-work
- Merge feature/complete

Skill Category 3: Merge and Rebase

Handling integration of changes is where Git gets complicated. These skills help.

merge-assistant

Guides through merge operations:

# Merge Assistant

Safely handle merge operations.

## Pre-Merge Checks

Before merging:
1. Ensure working directory is clean
2. Fetch latest from remote
3. Check CI status on source branch
4. Check for merge conflicts (dry run)
5. Verify PR approvals if required

## Conflict Resolution

When conflicts occur:
1. Identify conflicting files
2. For each conflict:
   - Show both versions with context
   - Explain what each side is doing
   - Suggest resolution strategy
3. After resolution, run tests
4. Complete merge if tests pass

## Merge Strategies

### Fast-Forward
When source is directly ahead of target:
`git merge --ff-only feature/branch`

### Merge Commit
Create explicit merge commit:
`git merge --no-ff feature/branch`

### Squash
Combine all commits into one:
`git merge --squash feature/branch`

## When to Use Each

**Fast-Forward**: Small, focused changes that don't need history preserved

**Merge Commit**: Feature branches where history is valuable

**Squash**: When the PR's commit history is messy and irrelevant

## Output

Pre-merge report:
- Source: feature/new-api (12 commits)
- Target: main
- Conflicts: 2 files (src/api/routes.ts, src/config.ts)
- CI Status: ✓ Passing
- Approvals: 2/2

Proceed with merge? (yes/resolve-conflicts-first/abort)

rebase-helper

Guides through rebase operations:

# Rebase Helper

Safely handle rebase operations.

## Rebase Safety Checks

Before rebasing:
1. Ensure no one else is using this branch
2. Check for pushed commits (warning if present)
3. Stash uncommitted changes
4. Create backup ref

## Interactive Rebase

For cleaning up history:

1. Analyze commits to be rebased
2. Suggest picks, squashes, and rewords
3. Show preview of resulting history
4. Execute rebase with confirmations

## Common Operations

### Update from Main
```bash
git fetch origin
git rebase origin/main

Squash Recent Commits

git rebase -i HEAD~N

Fix Specific Commit

git rebase -i COMMIT^
# Mark commit for edit

Conflict Resolution

For each conflict during rebase:

Show which commit caused conflict
Show the change being applied
Guide resolution
Continue or abort

Recovery

If rebase goes wrong:

git rebase --abort  # Abandon rebase
git reflog          # Find pre-rebase state
git reset --hard REF  # Return to safe state

Output

Rebase plan for feature/new-api onto main:

12 commits to replay:

abc123 feat: add endpoint (keep)
def456 fix typo (squash into previous)
ghi789 wip (squash into next)
jkl012 feat: complete implementation (keep) ...

Potential conflicts detected in:

src/api/routes.ts (both modified same function)

Proceed? (yes/edit-plan/dry-run/abort)


### conflict-resolver

Specialized skill for handling merge conflicts:

```markdown
# Conflict Resolver

Intelligent merge conflict resolution.

## Conflict Analysis

For each conflict:
1. Parse conflict markers
2. Identify which branch made which change
3. Understand the semantic difference
4. Determine if changes are compatible

## Resolution Strategies

### Take Theirs
When their change supersedes ours.

### Take Ours
When our change should be preserved.

### Combine
When both changes are valid and compatible.

### Manual
When changes conflict semantically.

## Example Resolution

File: src/api/routes.ts

<<<<<<< HEAD
app.get('/users', authenticate, listUsers)
=======
app.get('/users', rateLimit, listUsers)
>>>>>>> feature/security

Analysis:
- HEAD added authentication middleware
- feature/security added rate limiting middleware
- These changes are compatible (not conflicting)

Suggested resolution:
app.get('/users', authenticate, rateLimit, listUsers)

Both middlewares should apply. Order: authenticate first (to know who to rate limit).

Accept this resolution? (yes/take-ours/take-theirs/manual)

Skill Category 4: History and Analysis

Understanding Git history helps with debugging and review.

git-history-search

Searches Git history for specific changes:

# Git History Search

Find changes in Git history.

## Search Types

### By Content
Find commits that introduced specific code:
`git log -S "function_name" --all`

### By File
Find all commits touching a file:
`git log --follow -- path/to/file`

### By Author
Find commits by a specific person:
`git log --author="name"`

### By Date
Find commits in a date range:
`git log --after="2024-01-01" --before="2024-02-01"`

### By Message
Find commits with message matching pattern:
`git log --grep="feat:" --all`

## Process

1. Accept search criteria from user
2. Build appropriate git log command
3. Execute and parse results
4. Present with context

## Output

Search: "Where was validateEmail first introduced?"

Found in commit: abc123456
Author: Jane Developer
Date: 2024-03-15
Message: feat(auth): add email validation

File changed: src/utils/validation.ts
Lines 45-67: validateEmail function added

Related commits:
- def456789 (2024-03-16): Added tests for validateEmail
- ghi012345 (2024-03-20): Fixed regex in validateEmail

blame-analyzer

Enhanced git blame with context:

# Blame Analyzer

Understand who changed what and why.

## Beyond Basic Blame

For each line/region:
1. Who made the change
2. When it was made
3. The commit message explaining why
4. Related changes in same commit
5. PR/issue if available

## Usage

/blame src/api/routes.ts:45-60

## Output

Lines 45-60 of src/api/routes.ts

Last modified: abc123456 (Jane, 2024-03-15)
Commit message: feat(auth): add authentication middleware

This change was part of PR #234: "Add JWT authentication"
Issue: #123 "Implement user authentication"

The authentication middleware was added here because:
[excerpt from PR description or commit body]

Other files changed in same commit:
- src/auth/jwt.ts (added)
- src/auth/middleware.ts (added)
- tests/auth.test.ts (added)

Previous version (def456789, Bob, 2024-02-01):
[shows what this code looked like before]

bisect-assistant

Guides through git bisect to find bugs:

# Bisect Assistant

Find the commit that introduced a bug.

## Process

1. Identify a good commit (bug not present)
2. Identify a bad commit (bug present)
3. Start bisect
4. For each test commit:
   - Suggest what to test
   - Record result (good/bad)
   - Narrow range
5. Identify culprit commit

## Automation

If test can be automated:
```bash
git bisect run npm test

Manual Bisect

/bisect-start Good commit: abc123 (last known working) Bad commit: HEAD (current broken)

Testing: def456 (midpoint) Is the bug present? (good/bad/skip)

... 3 more steps ...

Found: ghi789 introduced the bug

Commit details: Author: Bob Developer Date: 2024-04-10 Message: refactor(parser): optimize parsing

Changed files:

src/parser/core.ts

Likely cause: Changed handling of edge case at line 127


## Skill Category 5: Workflow Integration

Skills that integrate Git with broader development workflows.

### pr-preparer

Prepares changes for pull request:

```markdown
# PR Preparer

Prepare your branch for pull request.

## Pre-PR Checklist

1. **Rebase on latest main**
   - Fetch main
   - Rebase or merge as preferred
   - Resolve any conflicts

2. **Clean up history** (optional)
   - Squash WIP commits
   - Reword unclear messages
   - Ensure atomic commits

3. **Run quality checks**
   - Run tests
   - Run linter
   - Check types

4. **Verify changes**
   - Review diff against main
   - Check nothing extra included
   - Confirm all files intended

5. **Push and create PR**
   - Push to remote
   - Generate PR description from commits
   - Open PR with template filled

## Output

PR Preparation for feature/new-api

✓ Rebased on main (was 3 commits behind)
✓ History cleaned (5 commits -> 3 logical commits)
✓ Tests passing
✓ Linting clean
✓ Types valid

Changes to include:
- src/api/routes.ts (+45 lines)
- src/api/handlers/*.ts (new handlers)
- tests/api/*.test.ts (new tests)

Ready to push and create PR? (yes/review-changes/abort)

release-manager

Manages release tagging and changelogs:

# Release Manager

Create releases with proper versioning.

## Version Determination

Based on conventional commits since last tag:
- Any feat commits -> MINOR bump
- Only fix commits -> PATCH bump
- Any breaking changes -> MAJOR bump

## Process

1. Determine new version number
2. Generate changelog from commits
3. Update version in package.json (if applicable)
4. Create version commit
5. Create annotated tag
6. Push tag to remote

## Changelog Generation

Group commits by type:
- Features (feat)
- Bug Fixes (fix)
- Performance (perf)
- Breaking Changes

## Output

Current version: 1.2.3
Commits since last release: 8

Commit analysis:
- 3 feat commits
- 4 fix commits
- 1 refactor commit
- No breaking changes

Suggested new version: 1.3.0 (MINOR bump)

Changelog preview:

## [1.3.0] - 2025-01-19

### Features
- Add OAuth2 login with Google (#142)
- Add password reset flow (#156)
- Add email notifications (#161)

### Bug Fixes
- Fix duplicate email registration (#287)
- Fix session timeout handling (#290)
- Fix password validation regex (#292)
- Fix mobile responsive layout (#295)

Create release 1.3.0? (yes/edit-changelog/different-version/abort)

Practical Configuration

Team Conventions

Customize skills with your team's rules:

# Our Git Conventions

## Commit Types (project-specific)
- feat: New feature
- fix: Bug fix
- perf: Performance improvement
- chore: Maintenance

We do NOT use: style, docs, refactor, test
(These are rolled into the above types)

## Branch Prefixes
- feature/ (not feat/)
- bugfix/ (not fix/)
- release/

## Merge Strategy
- Always squash merge to main
- Preserve history on release branches
- Never rebase shared branches

Integration with CI

## CI Integration

### Pre-Push Hook
Run /commit-lint on all new commits
Block push if validation fails

### PR Checks
- Verify branch naming convention
- Check commit message format
- Validate no merge commits (rebase only)

Conclusion

Git workflow skills transform version control from a source of friction into a streamlined process. Commit skills ensure consistent, meaningful history. Branch skills manage the lifecycle of work. Merge skills reduce anxiety around integration. History skills help understand past decisions.

The key is encoding your team's decisions once, then applying them consistently. Instead of documenting conventions in a wiki nobody reads, encode them in skills that actively enforce and assist.

Start with the skills that address your biggest Git pain points:

Inconsistent commits? Deploy conventional-commit.
Branch mess? Use branch-cleanup regularly.
Merge fear? Let merge-assistant guide you.
Lost context? Leverage blame-analyzer and git-history-search.

As these skills become part of your workflow, Git transforms from a necessary tool into a genuine asset. History becomes meaningful. Collaboration becomes smoother. And you can focus on writing code instead of managing version control.

Want to improve other parts of your development workflow? Check out Code Review Skills Roundup for PR automation, or explore Testing Skills Comparison for quality assurance workflows.

Git Workflow Skills: Commit, Branch, and Merge Automation

The Git Workflow Challenge

Despite Git's ubiquity, teams struggle with common issues:

Commit Message Chaos: Messages range from "fixed stuff" to multi-paragraph essays. No consistent format means history is hard to parse.

Branch Proliferation: Feature branches linger. Naming is inconsistent. It's unclear what's active versus abandoned.

Merge Anxiety: Complex merges feel risky. Conflicts require mental context reconstruction.

History Hygiene: When to squash? When to rebase? When to merge? Teams apply different strategies inconsistently.

Git skills don't just automate commands; they encode decisions about how your team uses Git.

Skill Category 1: Commit Skills

The most common Git skills focus on commits; the atomic unit of change.

conventional-commit

Generates commits following the Conventional Commits standard:

# Conventional Commit

Create commits following Conventional Commits specification.

## Format

type(scope): description

[optional body]

[optional footer(s)]

## Types

- feat: New feature (MINOR version bump)
- fix: Bug fix (PATCH version bump)
- docs: Documentation only changes
- style: Code style (formatting, missing semi-colons)
- refactor: Code change that neither fixes a bug nor adds a feature
- perf: Performance improvement
- test: Adding or correcting tests
- build: Build system or external dependency changes
- ci: CI configuration changes
- chore: Other changes that don't modify src or test files
- revert: Reverts a previous commit

## Scope (optional)

Component or area affected: (auth), (api), (ui), (db)

## Breaking Changes

Add ! after type or BREAKING CHANGE: in footer:
feat(api)!: remove deprecated endpoints

## Process

1. Run `git status` to see changed files
2. Run `git diff --staged` to analyze changes
3. Determine type from nature of changes
4. Identify scope from affected area
5. Write clear, imperative description
6. Add body if explanation needed
7. Add footer for breaking changes or issue references

## Examples

feat(auth): add OAuth2 login with Google

fix(parser): handle empty input without crashing

Fixes #142

docs: update README with new API endpoints

refactor(db)!: rename user_id to account_id

BREAKING CHANGE: All queries using user_id must be updated.

What Makes It Powerful

The skill analyzes your changes and suggests appropriate types and scopes:

User: /commit

Analyzing staged changes...

Files changed:
- src/auth/oauth.ts (new file, 145 lines)
- src/auth/providers/google.ts (new file, 82 lines)
- src/routes/auth.ts (modified, +23 lines)
- package.json (modified, added @googleapis/oauth2)
- tests/auth/oauth.test.ts (new file, 67 lines)

Suggested commit:

feat(auth): add Google OAuth2 authentication

- Implement OAuth2 flow with Google provider
- Add callback route for token exchange
- Include refresh token handling
- Add unit tests for OAuth flow

Shall I create this commit? (y/n/edit)

smart-commit

Goes beyond conventional format to analyze the semantic meaning of changes:

# Smart Commit

Intelligent commit message generation with context analysis.

## Analysis Depth

### File-Level
- What files changed
- Net additions/deletions
- File types affected

### Code-Level
- Functions added/modified/removed
- Classes changed
- Imports added
- Tests added

### Semantic-Level
- Purpose of changes (feature, fix, refactor)
- Relationship between changed files
- Breaking change detection

## Output

Generates commit message that explains:
- WHAT changed (summary)
- WHY it changed (context)
- HOW it relates to other changes (connections)

## Example

Instead of: "updated user service"

Generates:

fix(users): prevent duplicate email registration

When creating a user, the system now checks for existing emails
before insertion. Previously, a duplicate key error would occur
at the database level, returning a 500 error.

Now returns 400 with message "Email already registered" if
a user with the same email exists.

Fixes #287

commit-lint

Validates commit messages against standards:

# Commit Lint

Validate commit messages before they're finalized.

## Rules

### Structure
- Header line max 72 characters
- Body wrapped at 72 characters
- Blank line between header and body

### Type
- Must be valid type (feat, fix, etc.)
- Type must be lowercase

### Scope
- Must be lowercase
- No spaces (use hyphens)
- Optional but encouraged

### Description
- Must be present
- Imperative mood ("add" not "added")
- No period at end
- Lowercase start (after type)

### Body
- Explain what and why, not how
- May include bullet points

### Footer
- Issue references: Fixes #123
- Breaking changes: BREAKING CHANGE: description

## Validation Output

✓ Type 'feat' is valid
✓ Scope 'auth' is valid
✓ Description is imperative mood
✗ Header exceeds 72 characters (84)
✗ Missing blank line before body

Suggested fix:
[reformatted message]

Skill Category 2: Branch Management

Branch skills help with the lifecycle of feature and fix branches.

branch-creator

Creates branches with consistent naming:

# Branch Creator

Create branches following team conventions.

## Naming Convention

{type}/{issue-number}-{short-description}

## Types

- feature/ - New functionality
- fix/ - Bug fixes
- hotfix/ - Production fixes
- chore/ - Maintenance tasks
- docs/ - Documentation updates
- refactor/ - Code restructuring
- test/ - Test additions

## Process

1. Get branch type from user or infer from context
2. Get issue number if applicable
3. Get short description
4. Sanitize description (lowercase, hyphens)
5. Create branch from appropriate base

## Examples

feature/142-add-oauth-login
fix/287-prevent-duplicate-emails
hotfix/301-security-patch
chore/update-dependencies
docs/api-documentation

## Integration

When creating from issue:
/branch-create #142

Fetches issue title, extracts key words, suggests branch name.

branch-cleanup

Manages branch hygiene:

# Branch Cleanup

Clean up stale and merged branches.

## Detection

### Merged Branches
Branches fully merged to main/master:
`git branch --merged main`

### Stale Branches
Branches with no commits in 30+ days:
`git for-each-ref --sort=-committerdate refs/heads/`

### Gone Branches
Local branches whose remote is deleted:
`git branch -vv | grep ': gone]'`

## Process

1. Fetch latest from remote
2. Identify candidates for cleanup
3. Present list with last commit dates
4. Confirm before deletion
5. Delete local and remote branches

## Safety

- Never delete main, master, develop, or release branches
- Require confirmation for each deletion
- Show last commit to verify branch is truly obsolete
- Offer to archive rather than delete

## Output

### Merged Branches (safe to delete)
- feature/142-oauth-login (merged 3 days ago)
- fix/287-duplicate-emails (merged 1 week ago)

### Stale Branches (no activity 30+ days)
- feature/old-experiment (last commit: 2 months ago)

### Gone Branches (remote deleted)
- feature/completed-feature

Delete these branches? (all/select/cancel)

branch-status

Provides overview of all branches:

# Branch Status

Get a clear picture of all branches and their status.

## Information Collected

For each branch:
- Last commit date
- Commits ahead/behind main
- PR status (if exists)
- CI status (if available)
- Author of last commit

## Output

### Active Development
| Branch | Last Commit | Ahead | Behind | PR | CI |
|--------|-------------|-------|--------|-----|-----|
| feature/new-api | 2 hours ago | 12 | 3 | #456 | ✓ |
| fix/login-bug | 1 day ago | 3 | 0 | #457 | ✗ |

### Needs Attention
| Branch | Issue |
|--------|-------|
| feature/old-work | 45 commits behind, no PR |
| fix/stale | No activity 3 weeks |

### Ready to Merge
| Branch | PR | Approvals |
|--------|-----|-----------|
| feature/complete | #455 | 2/2 |

### Recommendations
- Rebase feature/new-api (3 commits behind)
- Review or close feature/old-work
- Merge feature/complete

Skill Category 3: Merge and Rebase

Handling integration of changes is where Git gets complicated. These skills help.

merge-assistant

Guides through merge operations:

# Merge Assistant

Safely handle merge operations.

## Pre-Merge Checks

Before merging:
1. Ensure working directory is clean
2. Fetch latest from remote
3. Check CI status on source branch
4. Check for merge conflicts (dry run)
5. Verify PR approvals if required

## Conflict Resolution

When conflicts occur:
1. Identify conflicting files
2. For each conflict:
   - Show both versions with context
   - Explain what each side is doing
   - Suggest resolution strategy
3. After resolution, run tests
4. Complete merge if tests pass

## Merge Strategies

### Fast-Forward
When source is directly ahead of target:
`git merge --ff-only feature/branch`

### Merge Commit
Create explicit merge commit:
`git merge --no-ff feature/branch`

### Squash
Combine all commits into one:
`git merge --squash feature/branch`

## When to Use Each

**Fast-Forward**: Small, focused changes that don't need history preserved

**Merge Commit**: Feature branches where history is valuable

**Squash**: When the PR's commit history is messy and irrelevant

## Output

Pre-merge report:
- Source: feature/new-api (12 commits)
- Target: main
- Conflicts: 2 files (src/api/routes.ts, src/config.ts)
- CI Status: ✓ Passing
- Approvals: 2/2

Proceed with merge? (yes/resolve-conflicts-first/abort)

rebase-helper

Guides through rebase operations:

# Rebase Helper

Safely handle rebase operations.

## Rebase Safety Checks

Before rebasing:
1. Ensure no one else is using this branch
2. Check for pushed commits (warning if present)
3. Stash uncommitted changes
4. Create backup ref

## Interactive Rebase

For cleaning up history:

1. Analyze commits to be rebased
2. Suggest picks, squashes, and rewords
3. Show preview of resulting history
4. Execute rebase with confirmations

## Common Operations

### Update from Main
```bash
git fetch origin
git rebase origin/main

Squash Recent Commits

git rebase -i HEAD~N

Fix Specific Commit

git rebase -i COMMIT^
# Mark commit for edit

Conflict Resolution

For each conflict during rebase:

Show which commit caused conflict
Show the change being applied
Guide resolution
Continue or abort

Recovery

If rebase goes wrong:

git rebase --abort  # Abandon rebase
git reflog          # Find pre-rebase state
git reset --hard REF  # Return to safe state

Output

Rebase plan for feature/new-api onto main:

12 commits to replay:

abc123 feat: add endpoint (keep)
def456 fix typo (squash into previous)
ghi789 wip (squash into next)
jkl012 feat: complete implementation (keep) ...

Potential conflicts detected in:

src/api/routes.ts (both modified same function)

Proceed? (yes/edit-plan/dry-run/abort)


### conflict-resolver

Specialized skill for handling merge conflicts:

```markdown
# Conflict Resolver

Intelligent merge conflict resolution.

## Conflict Analysis

For each conflict:
1. Parse conflict markers
2. Identify which branch made which change
3. Understand the semantic difference
4. Determine if changes are compatible

## Resolution Strategies

### Take Theirs
When their change supersedes ours.

### Take Ours
When our change should be preserved.

### Combine
When both changes are valid and compatible.

### Manual
When changes conflict semantically.

## Example Resolution

File: src/api/routes.ts

<<<<<<< HEAD
app.get('/users', authenticate, listUsers)
=======
app.get('/users', rateLimit, listUsers)
>>>>>>> feature/security

Analysis:
- HEAD added authentication middleware
- feature/security added rate limiting middleware
- These changes are compatible (not conflicting)

Suggested resolution:
app.get('/users', authenticate, rateLimit, listUsers)

Both middlewares should apply. Order: authenticate first (to know who to rate limit).

Accept this resolution? (yes/take-ours/take-theirs/manual)

Skill Category 4: History and Analysis

Understanding Git history helps with debugging and review.

git-history-search

Searches Git history for specific changes:

# Git History Search

Find changes in Git history.

## Search Types

### By Content
Find commits that introduced specific code:
`git log -S "function_name" --all`

### By File
Find all commits touching a file:
`git log --follow -- path/to/file`

### By Author
Find commits by a specific person:
`git log --author="name"`

### By Date
Find commits in a date range:
`git log --after="2024-01-01" --before="2024-02-01"`

### By Message
Find commits with message matching pattern:
`git log --grep="feat:" --all`

## Process

1. Accept search criteria from user
2. Build appropriate git log command
3. Execute and parse results
4. Present with context

## Output

Search: "Where was validateEmail first introduced?"

Found in commit: abc123456
Author: Jane Developer
Date: 2024-03-15
Message: feat(auth): add email validation

File changed: src/utils/validation.ts
Lines 45-67: validateEmail function added

Related commits:
- def456789 (2024-03-16): Added tests for validateEmail
- ghi012345 (2024-03-20): Fixed regex in validateEmail

blame-analyzer

Enhanced git blame with context:

# Blame Analyzer

Understand who changed what and why.

## Beyond Basic Blame

For each line/region:
1. Who made the change
2. When it was made
3. The commit message explaining why
4. Related changes in same commit
5. PR/issue if available

## Usage

/blame src/api/routes.ts:45-60

## Output

Lines 45-60 of src/api/routes.ts

Last modified: abc123456 (Jane, 2024-03-15)
Commit message: feat(auth): add authentication middleware

This change was part of PR #234: "Add JWT authentication"
Issue: #123 "Implement user authentication"

The authentication middleware was added here because:
[excerpt from PR description or commit body]

Other files changed in same commit:
- src/auth/jwt.ts (added)
- src/auth/middleware.ts (added)
- tests/auth.test.ts (added)

Previous version (def456789, Bob, 2024-02-01):
[shows what this code looked like before]

bisect-assistant

Guides through git bisect to find bugs:

# Bisect Assistant

Find the commit that introduced a bug.

## Process

1. Identify a good commit (bug not present)
2. Identify a bad commit (bug present)
3. Start bisect
4. For each test commit:
   - Suggest what to test
   - Record result (good/bad)
   - Narrow range
5. Identify culprit commit

## Automation

If test can be automated:
```bash
git bisect run npm test

Manual Bisect

/bisect-start Good commit: abc123 (last known working) Bad commit: HEAD (current broken)

Testing: def456 (midpoint) Is the bug present? (good/bad/skip)

... 3 more steps ...

Found: ghi789 introduced the bug

Commit details: Author: Bob Developer Date: 2024-04-10 Message: refactor(parser): optimize parsing

Changed files:

src/parser/core.ts

Likely cause: Changed handling of edge case at line 127


## Skill Category 5: Workflow Integration

Skills that integrate Git with broader development workflows.

### pr-preparer

Prepares changes for pull request:

```markdown
# PR Preparer

Prepare your branch for pull request.

## Pre-PR Checklist

1. **Rebase on latest main**
   - Fetch main
   - Rebase or merge as preferred
   - Resolve any conflicts

2. **Clean up history** (optional)
   - Squash WIP commits
   - Reword unclear messages
   - Ensure atomic commits

3. **Run quality checks**
   - Run tests
   - Run linter
   - Check types

4. **Verify changes**
   - Review diff against main
   - Check nothing extra included
   - Confirm all files intended

5. **Push and create PR**
   - Push to remote
   - Generate PR description from commits
   - Open PR with template filled

## Output

PR Preparation for feature/new-api

✓ Rebased on main (was 3 commits behind)
✓ History cleaned (5 commits -> 3 logical commits)
✓ Tests passing
✓ Linting clean
✓ Types valid

Changes to include:
- src/api/routes.ts (+45 lines)
- src/api/handlers/*.ts (new handlers)
- tests/api/*.test.ts (new tests)

Ready to push and create PR? (yes/review-changes/abort)

release-manager

Manages release tagging and changelogs:

# Release Manager

Create releases with proper versioning.

## Version Determination

Based on conventional commits since last tag:
- Any feat commits -> MINOR bump
- Only fix commits -> PATCH bump
- Any breaking changes -> MAJOR bump

## Process

1. Determine new version number
2. Generate changelog from commits
3. Update version in package.json (if applicable)
4. Create version commit
5. Create annotated tag
6. Push tag to remote

## Changelog Generation

Group commits by type:
- Features (feat)
- Bug Fixes (fix)
- Performance (perf)
- Breaking Changes

## Output

Current version: 1.2.3
Commits since last release: 8

Commit analysis:
- 3 feat commits
- 4 fix commits
- 1 refactor commit
- No breaking changes

Suggested new version: 1.3.0 (MINOR bump)

Changelog preview:

## [1.3.0] - 2025-01-19

### Features
- Add OAuth2 login with Google (#142)
- Add password reset flow (#156)
- Add email notifications (#161)

### Bug Fixes
- Fix duplicate email registration (#287)
- Fix session timeout handling (#290)
- Fix password validation regex (#292)
- Fix mobile responsive layout (#295)

Create release 1.3.0? (yes/edit-changelog/different-version/abort)

Practical Configuration

Team Conventions

Customize skills with your team's rules:

# Our Git Conventions

## Commit Types (project-specific)
- feat: New feature
- fix: Bug fix
- perf: Performance improvement
- chore: Maintenance

We do NOT use: style, docs, refactor, test
(These are rolled into the above types)

## Branch Prefixes
- feature/ (not feat/)
- bugfix/ (not fix/)
- release/

## Merge Strategy
- Always squash merge to main
- Preserve history on release branches
- Never rebase shared branches

Integration with CI

## CI Integration

### Pre-Push Hook
Run /commit-lint on all new commits
Block push if validation fails

### PR Checks
- Verify branch naming convention
- Check commit message format
- Validate no merge commits (rebase only)

Conclusion

The key is encoding your team's decisions once, then applying them consistently. Instead of documenting conventions in a wiki nobody reads, encode them in skills that actively enforce and assist.

Start with the skills that address your biggest Git pain points:

Inconsistent commits? Deploy conventional-commit.
Branch mess? Use branch-cleanup regularly.
Merge fear? Let merge-assistant guide you.
Lost context? Leverage blame-analyzer and git-history-search.

Want to improve other parts of your development workflow? Check out Code Review Skills Roundup for PR automation, or explore Testing Skills Comparison for quality assurance workflows.