git-workflow

Included with Lifetime

$97 forever

This skill should be used when the user asks to "create git commit", "manage branches", "follow git workflow", "use Conventional Commits", "handle merge conflicts", or asks about git branching strategies, version control best practices, pull request workflows. Provides comprehensive Git workflow guidance for team collaboration.

General

What this skill does


# 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. **Communication** - Avoid modifying the same file simultaneously

For detailed conflict handling and advanced techniques, see `references/conflict-resolution.md`.

## .gitignore Standards

### Basic Rules

```
# Ignore all .log files
*.log

# Ignore directories
node_modules/

# Ignore directory at root
/temp/

# Ignore files in all directories
**/.env

# Don't ignore specific files
!.gitkeep
```

### Common .gitignore

```
node_modules/
dist/
build/
.idea/
.vscode/
.env
.env.local
logs/
*.log
.DS_Store
Thumbs.db
```

For detailed .gitignore patterns and project-specific configurations, see `references/gitignore-guide.md`.

## Tag Management

Uses **Semantic Versioning**:

```
MAJOR.MINOR.PATCH[-PRERELEASE]
```

### Version Change Rules

- **MAJOR**: Incompatible API changes (v1.0.0 → v2.0.0)
- **MINOR**: Backward-compatible new features (v1.0.0 → v1.1.0)
- **PATCH**: Backward-compatible bug fixes (v1.0.0 → v1.0.1)

### Tag Operations

```bash
# Create annotated tag (recommended)
git tag -a v1.0.0 -m "release: v1.0.0 official release"

# Push tags
git push origin v1.0.0
git push origin --tags

# View tags
git tag
git show v1.0.0

# Delete tag
git tag -d v1.0.0
git push origin :refs/tags/v1.0.0
```

## Team Collaboration Standards

### Pull Request Standards

PRs should include:

```markdown
## Change Description
<!-- Describe the content and purpose of this change -->

## Change Type
- [ ] New feature (feat)
- [ ] Bug fix (fix)
- [ ] Code refactoring (refactor)

## Testing Method
<!-- Describe how to test -->

## Related Issue
Closes #xxx

## Checklist
- [ ] Code has been self-tested
- [ ] Documentation has been updated
```

### Code Review Standards

Review focus areas:
- **Code quality**: Clear and readable, proper naming, no duplicate code
- **Logic correctness**: Business logic correct, edge cases handled
- **Security**: No security vulnerabilities, sensitive information protected
- **Performance**: No obvious performance issues, resources properly released

For detai

Files: 10

Size: 42.5 KB

Complexity: 59/100

Category: General

Source: https://github.com/galaxy-dawn/claude-scholar/tree/main/skills/git-workflow

Related in General

modeling-omnistudio-epc-catalog

Included

Salesforce Industries CME EPC product-modeling skill for Product2-based catalog creation. Use when creating EPC products, configuring product attributes, building offer bundles with Product Child Items, or reviewing EPC DataPack JSON metadata for product catalog changes. TRIGGER when: user creates or updates Product2 EPC records, AttributeAssignment payloads, AttributeMetadata/AttributeDefaultValues, Offer bundles, or ProductChildItem relationships. DO NOT TRIGGER when: designing OmniScripts/FlexCards/Integration Procedures (use building-omnistudio-omniscript, building-omnistudio-flexcard, or building-omnistudio-integration-procedure), implementing Apex business logic (use generating-apex), or troubleshooting deployment pipelines (use deploying-metadata).

Generalscripts

relationship-science-coach

Included

Use this skill for direct, practical adult relationship coaching: couples conflict, repair, trust, marriage, dating, flirting, attachment patterns, emotional connection, sex, desire differences, eroticism, kink negotiation, affection, love languages, breakups, and long-term passion. Draw on Gottman, EFT and Hold Me Tight, attachment science, modern sex research, Perel, Nagoski, Kerner, Schnarch, Love and Stosny, and flexible love-language tools. Be concrete and low-hedge. Redirect only for imminent danger, abuse, coercive control, minors, non-consent, self-harm, stalking, or medical/legal/psychiatric decisions.

Generalscripts

building-sf-integrations

Included

Salesforce integration architecture and runtime plumbing with 120-point scoring. Use this skill to set up Named Credentials, External Credentials, External Services, REST/SOAP callout patterns, Platform Events, and Change Data Capture. TRIGGER when: user sets up Named Credentials, External Services, REST/SOAP callouts, Platform Events, CDC, or touches .namedCredential-meta.xml files. DO NOT TRIGGER when: Connected App/OAuth config (use configuring-connected-apps), Apex-only logic (use generating-apex), or data import/export (use handling-sf-data).

Generalscripts

venue-templates

Included

Access comprehensive LaTeX templates, formatting requirements, and submission guidelines for major scientific publication venues (Nature, Science, PLOS, IEEE, ACM), academic conferences (NeurIPS, ICML, CVPR, CHI), research posters, and grant proposals (NSF, NIH, DOE, DARPA). This skill should be used when preparing manuscripts for journal submission, conference papers, research posters, or grant proposals and need venue-specific formatting requirements and templates.

Generalscripts

let-fate-decide

Included

Draws the 12 Houses of the Zodiac Tarot spread to inject entropy into planning when prompts are vague, ambiguous, or casually delegated. Interprets the spread to guide next steps. Use when the user says 'let fate decide', 'YOLO', 'whatever', 'idk', or other nonchalant phrases, makes Yu-Gi-Oh references, or when you are about to arbitrarily pick between multiple reasonable approaches. Prefer over ask-questions-if-underspecified when the user's tone is casual or playful rather than precision-seeking.

Generalscripts

net-ops

Included

Cross-platform network troubleshooting (Windows, macOS, Linux) via local or remote shell. Use for: DNS broken, can't resolve hostnames, nslookup/dig works but apps fail, NRPT, WFP, scutil, /etc/resolver, systemd-resolved, /etc/resolv.conf, NetworkManager, VPN DNS leak residue (ProtonVPN/Mullvad/WireGuard/AnyConnect), AV/firewall blocking DNS or DoH, Tailscale DNS interaction, intermittent connectivity, remote diagnostics over SSH.

Generalscripts