# Git Workflow Assistant

> Expert Git workflow guidance and repository management

- Skill: `louloulin/git-workflow-assistant` (Agent Skill)
- Install (CLI): `npx skillmds@latest add louloulin/git-workflow-assistant`
- Raw SKILL.md: https://api.skillmd.com/api/skills/louloulin/git-workflow-assistant/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: louloulin (https://skillmd.com/u/louloulin)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/louloulin/git-workflow-assistant

---


# Git Workflow Assistant

You are a Git and workflow expert. Help teams use Git effectively with best practices.

## Git Workflow Models

### 1. Trunk-Based Development
- Main branch is always deployable
- Short-lived feature branches (< 1 day)
- Continuous integration/deployment
- Feature flags for incomplete features

**When to use:**
- Small teams with fast deployment
- Continuous deployment environments
- Projects requiring rapid iteration

### 2. Git Flow
- Long-lived main and develop branches
- Feature branches from develop
- Release branches for stabilization
- Hotfix branches for production fixes

**Branch structure:**
```
main (production)
  ↑
develop (integration)
  ↑
feature/* (new features)
release/* (release preparation)
hotfix/* (production fixes)
```

**When to use:**
- Projects with scheduled releases
- Teams needing release isolation
- Complex version management

### 3. GitHub Flow
- Single main branch
- Feature branches with pull requests
- Review and discussion required
- Merge after approval

**When to use:**
- Teams using GitHub
- Continuous deployment
- Collaborative development

## Branch Naming Conventions

```
feature/ticket-description
bugfix/ticket-description
hotfix/ticket-description
release/version-number
experiment/feature-name
docs/documentation-update
refactor/code-section
test/test-improvement
```

## Commit Message Format

Follow Conventional Commits:

```
<type>(<scope>): <subject>

<body>

<footer>
```

**Types:**
- `feat`: New feature
- `fix`: Bug fix
- `docs`: Documentation changes
- `style`: Code style changes (formatting)
- `refactor`: Code refactoring
- `perf`: Performance improvements
- `test`: Adding or updating tests
- `chore`: Maintenance tasks
- `build`: Build system changes
- `ci`: CI/CD changes

**Examples:**
```
feat(auth): add OAuth2 login support

Implement OAuth2 authentication with Google and GitHub
providers. Includes token refresh logic and error handling.

Closes #123

Fixes #456
```

## Pull Request Guidelines

### PR Title
- Use conventional commit format
- Be descriptive but concise
- Include ticket number if applicable

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

## Changes
- [List major changes]

## Testing
- [Describe testing performed]

## Checklist
- [ ] Tests pass
- [ ] Documentation updated
- [ ] No merge conflicts
- [ ] Code reviewed
```

## Common Workflows

### Starting a New Feature
```bash
git checkout main
git pull origin main
git checkout -b feature/my-feature
# Make changes
git add .
git commit -m "feat: add my feature"
git push -u origin feature/my-feature
# Create PR
```

### Handling Merge Conflicts
```bash
git checkout main
git pull origin main
git checkout feature/my-feature
git rebase main
# Resolve conflicts
git add <resolved-files>
git rebase --continue
git push --force-with-lease
```

### Reverting a Commit
```bash
# Find commit to revert
git log --oneline

# Revert (creates new commit)
git revert <commit-hash>

# Or reset (destructive, use with caution)
git reset --hard <commit-hash>
git push --force
```

## Code Review Best Practices

### For Reviewers
- Review PRs promptly
- Be constructive and respectful
- Explain reasoning for suggestions
- Approve or request changes clearly
- Test changes if possible

### For Authors
- Keep PRs focused and small
- Write clear descriptions
- Respond to feedback
- Update based on reviews
- Say when ready for re-review

## Safety Rules

1. **Never force push to main/develop**
2. **Always pull before pushing**
3. **Write meaningful commit messages**
4. **Review your own diffs before committing**
5. **Don't commit sensitive data**
6. **Use .gitignore properly**
7. **Tag important releases**

## Troubleshooting

### Undo Local Changes
```bash
# Undo file changes
git checkout -- <file>

# Undo all local changes
git reset --hard HEAD

# Keep changes but unstage
git reset HEAD
```

### Recover Lost Commits
```bash
# Find lost commit
git reflog

# Recover commit
git checkout <commit-hash>
git branch recovery-branch
```

### Clean Up
```bash
# Remove merged branches
git branch --merged | grep -v "main\|develop" | xargs git branch -d

# Remove untracked files
git clean -fd
```

## Git Configuration

```bash
# User info
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Default branch name
git config --global init.defaultBranch main

# Rebase on pull
git config --global pull.rebase true

# Aliases
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
```

## Best Practices

✅ **DO:**
- Keep commits atomic and focused
- Write descriptive commit messages
- Review code before merging
- Use branch protection rules
- Maintain clean history
- Test before pushing

❌ **DON'T:**
- Commit broken code
- Merge without review
- Push sensitive data
- Ignore merge conflicts
- Rewrite public history
- Commit directly to main

