Skip to main content
ClaudeWave
Skill4.3k repo starsupdated 7d ago

git-workflow

The git-workflow skill provides comprehensive guidance on implementing standardized Git practices for team projects, including Conventional Commits message formatting, branch naming and protection strategies, and collaborative workflows. Use this skill when users need to create commits following standards, manage repository branches, handle merge conflicts, implement pull request workflows, or establish version control best practices for team collaboration.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/Galaxy-Dawn/claude-scholar /tmp/git-workflow && cp -r /tmp/git-workflow/skills/git-workflow ~/.claude/skills/git-workflow
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# Git Workflow Standards

This document defines the project's Git usage standards, including commit message format, branch management strategy, workflows, merge strategies, and more. Following these standards improves collaboration efficiency, enables traceability, supports automation, and reduces conflicts.

## Commit Message Standards

The project follows the **Conventional Commits** specification:

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

<body>

<footer>
```

### Type Reference

| Type | Description | Example |
| :--- | :--- | :--- |
| `feat` | New feature | `feat(user): add user export functionality` |
| `fix` | Bug fix | `fix(login): fix captcha not refreshing` |
| `docs` | Documentation update | `docs(api): update API documentation` |
| `refactor` | Refactoring | `refactor(utils): refactor utility functions` |
| `perf` | Performance improvement | `perf(list): optimize list performance` |
| `test` | Test related | `test(user): add unit tests` |
| `chore` | Other changes | `chore: update dependency versions` |

### Subject Rules

- Start with a verb: add, fix, update, remove, optimize
- No more than 50 characters
- No period at the end

For more detailed conventions and examples, see `references/commit-conventions.md`.

## Branch Management Strategy

### Branch Types

| Branch Type | Naming Convention | Description | Lifecycle |
| :--- | :--- | :--- | :--- |
| master | `master` | Main branch, releasable state | Permanent |
| develop | `develop` | Development branch, latest integrated code | Permanent |
| feature | `feature/feature-name` | Feature branch | Delete after completion |
| bugfix | `bugfix/issue-description` | Bug fix branch | Delete after fix |
| hotfix | `hotfix/issue-description` | Emergency fix branch | Delete after fix |
| release | `release/version-number` | Release branch | Delete after release |

### Branch Naming Examples

```
feature/user-management          # User management feature
feature/123-add-export          # Issue-linked feature
bugfix/login-error              # Login error fix
hotfix/security-vulnerability   # Security vulnerability fix
release/v1.0.0                  # Version release
```

### Branch Protection Rules

**master branch:**
- No direct pushes allowed
- Must merge via Pull Request
- Must pass CI checks
- Requires at least one Code Review approval

**develop branch:**
- Direct pushes restricted
- Pull Request merges recommended
- Must pass CI checks

For detailed branch strategies and workflows, see `references/branching-strategies.md`.

## Workflows

### Daily Development Workflow

```bash
# 1. Sync latest code
git checkout develop
git pull origin develop

# 2. Create feature branch
git checkout -b feature/user-management

# 3. Develop and commit
git add .
git commit -m "feat(user): add user list page"

# 4. Push to remote
git push -u origin feature/user-management

# 5. Create Pull Request and request Code Review

# 6. Merge to develop (via PR)

# 7. Delete feature branch
git branch -d feature/user-management
git push origin -d feature/user-management
```

### Hotfix Workflow

```bash
# 1. Create fix branch from master
git checkout master
git pull origin master
git checkout -b hotfix/critical-bug

# 2. Fix and commit
git add .
git commit -m "fix(auth): fix authentication bypass vulnerability"

# 3. Merge to master
git checkout master
git merge --no-ff hotfix/critical-bug
git tag -a v1.0.1 -m "hotfix: fix authentication bypass vulnerability"
git push origin master --tags

# 4. Sync to develop
git checkout develop
git merge --no-ff hotfix/critical-bug
git push origin develop
```

### Release Workflow

```bash
# 1. Create release branch
git checkout develop
git checkout -b release/v1.0.0

# 2. Update version numbers and documentation

# 3. Commit version update
git add .
git commit -m "chore(release): prepare release v1.0.0"

# 4. Merge to master
git checkout master
git merge --no-ff release/v1.0.0
git tag -a v1.0.0 -m "release: v1.0.0 official release"
git push origin master --tags

# 5. Sync to develop
git checkout develop
git merge --no-ff release/v1.0.0
git push origin develop
```

## Merge Strategy

### Merge vs Rebase

| Feature | Merge | Rebase |
| :--- | :--- | :--- |
| History | Preserves complete history | Linear history |
| Use case | Public branches | Private branches |
| Recommended for | Merging to main branch | Syncing upstream code |

### Recommendations

- **Feature branch syncing develop**: Use `rebase`
- **Feature branch merging to develop**: Use `merge --no-ff`
- **develop merging to master**: Use `merge --no-ff`

```bash
# ✅ Recommended: Feature branch syncing develop
git checkout feature/user-management
git rebase develop

# ✅ Recommended: Merge feature branch to develop
git checkout develop
git merge --no-ff feature/user-management

# ❌ Not recommended: Rebase on public branch
git checkout develop
git rebase feature/xxx  # Dangerous operation
```

**Project convention**: Use `--no-ff` when merging feature branches to preserve branch history.

For detailed merge strategies and techniques, see `references/merge-strategies.md`.

## Conflict Resolution

### Identifying Conflicts

```
<<<<<<< HEAD
// Current branch code
const name = 'Alice'
=======
// Branch being merged
const name = 'Bob'
>>>>>>> feature/user-management
```

### Resolving Conflicts

```bash
# 1. View conflicting files
git status

# 2. Manually edit files to resolve conflicts

# 3. Mark as resolved
git add <file>

# 4. Complete the merge
git commit  # merge conflict
# or
git rebase --continue  # rebase conflict
```

### Conflict Resolution Strategies

```bash
# Keep current branch version
git checkout --ours <file>

# Keep incoming branch version
git checkout --theirs <file>

# Abort merge
git merge --abort
git rebase --abort
```

### Preventing Conflicts

1. **Sync code regularly** - Pull latest code before starting work each day
2. **Small commits** - Commit small changes frequently
3. **Modular features** - Implement different features in different files
4. **Com
code-reviewerSubagent

Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code. MUST BE USED for all code changes.

kaggle-minerSubagent

Use this agent when the user provides a Kaggle competition URL or asks to learn from Kaggle winning solutions. Examples:

literature-reviewerSubagent

Use this agent when the user asks to "conduct literature review", "search for papers", "analyze research papers", "identify research gaps", "review related work", or mentions starting a research project. This agent integrates with Zotero for automated paper collection, organization, and full-text analysis. Examples:

paper-minerSubagent

Use this agent when the user provides a research paper (PDF/DOCX/arXiv link) or asks to learn writing patterns from papers, extract venue-specific writing signals, study paper structure, or mine rebuttal strategies. The agent writes extracted knowledge into the active installed paper-miner writing memory for ml-paper-writing. It does not maintain project-specific writing memory.

rebuttal-writerSubagent

Use this agent when the user asks to "write rebuttal", "respond to reviewers", "analyze review comments", or needs help with academic paper review response. This agent specializes in systematic rebuttal writing with professional tone and structured responses.

tdd-guideSubagent

Test-driven development guide for writing tests first, implementing the smallest passing change, and keeping verification tight. Use when the user explicitly wants TDD or when a task should be driven by failing tests before code.

analyze-resultsSlash Command

Run a blocker-first post-experiment workflow: validate evidence, produce strict statistical analysis when possible, and generate a decision-oriented results report only when the analysis bundle is sufficient. Uses results-analysis + results-report as a gated two-stage workflow.

commitSlash Command

Commit changes following Conventional Commits format (local only, no push).