git-workflow

Included with Lifetime

$97 forever

Git workflow management with atomic commit principles. Capabilities: commit organization, branching strategies, merge/rebase workflows, PR management, history cleanup, staged change analysis, single-responsibility commits. Actions: commit, push, pull, merge, rebase, branch, stage, stash git operations. Keywords: git commit, git push, git pull, git merge, git rebase, git branch, git stash, atomic commit, commit message, conventional commits, branching strategy, GitFlow, trunk-based, PR, pull request, code review, git history, cherry-pick, squash, amend, interactive rebase, staged changes. Use when: organizing commits, creating branches, merging code, rebasing, writing commit messages, managing PRs, cleaning git history, analyzing staged changes.

Writing & Docs

What this skill does


# Git Workflow & Best Practices

## Purpose

Comprehensive guide for git operations with emphasis on clean history, atomic commits, and professional workflows. Automatically analyzes staged changes and enforces single-responsibility principle.

## When to Use

Activate for any git operation:
- Committing changes (especially multiple files)
- Creating branches
- Merging or rebasing
- Managing git history
- Writing commit messages
- Organizing staging area
- Code review preparation
- Repository management

## Core Philosophy

### Single Responsibility Rule ⭐

**CRITICAL:** Before committing, analyze staged changes and divide into atomic commits.

**Process:**
1. Run `git status` to see all staged files
2. Identify different concerns/features
3. Unstage everything: `git reset HEAD`
4. Stage files by concern, one group at a time
5. Commit each group with focused message
6. Repeat until all changes are committed

**Why:** Makes history reviewable, revertable, and maintainable.

---

## Commit Organization

### Analyzing Staged Changes

```bash
# Check what's staged
git status

# See file-level summary
git diff --cached --stat

# See detailed changes
git diff --cached

# Check specific file
git diff --cached path/to/file
```

### Grouping Strategies

**By Feature:**
- Auth system changes → one commit
- Payment module → separate commit
- User profile → another commit

**By Layer:**
- Database migrations → first commit
- Backend API → second commit
- Frontend UI → third commit
- Tests → fourth commit

**By Type:**
- New features (feat)
- Bug fixes (fix)
- Refactoring (refactor)
- Documentation (docs)
- Performance (perf)
- Tests (test)

**By Dependency:**
- Foundation/infrastructure first
- Features that depend on foundation second

### Division Workflow

```bash
# 1. Analyze current state
git status
git diff --cached --stat

# 2. Unstage everything
git reset HEAD

# 3. Stage first logical group
git add file1.ts file2.ts directory/

# 4. Verify what's staged
git diff --cached --stat

# 5. Commit with focused message
git commit -m "type: concise description"

# 6. Repeat steps 3-5 for remaining groups
```

### Example: Real Scenario

**Situation:** 29 files staged with mixed concerns

```bash
# Before - messy staging
$ git status
Changes to be committed:
  # Trading Styles feature (25 files)
  modified:   src/app/styles/page.tsx
  new file:   src/core/domain/models/TradingStyle.ts
  new file:   src/infrastructure/database/migrations/create_trading_styles.ts
  ...
  # History enhancements (4 files)
  modified:   src/app/history/page.tsx
  modified:   src/app/api/history/recommendations/route.ts
  ...
```

**Solution:**

```bash
# 1. Reset staging
git reset HEAD

# 2. Commit #1 - Trading Styles feature
git add \
  package.json pnpm-lock.yaml \
  src/app/styles/ \
  src/core/domain/models/TradingStyle.ts \
  src/core/ports/ITradingStyleRepository.ts \
  src/infrastructure/database/TradingStyleRepository.ts \
  src/infrastructure/database/migrations/create_trading_styles.ts

git commit -m "feat: Add trading style persona system for AI-powered analysis"

# 3. Commit #2 - History enhancements
git add \
  src/app/history/page.tsx \
  src/app/api/history/recommendations/route.ts \
  src/infrastructure/database/TimeseriesRepository.ts \
  src/components/layout/AppLayout.tsx

git commit -m "feat: Add comprehensive search and filtering to history page"
```

**Result:** Clean, focused commits that are independently reviewable and revertable.

---

## Commit Messages

### Conventional Commits Format

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

<body>

<footer>
```

### Types

- `feat` - New feature
- `fix` - Bug fix
- `refactor` - Code restructuring (no behavior change)
- `perf` - Performance improvement
- `docs` - Documentation only
- `style` - Formatting, whitespace, semicolons
- `test` - Adding/updating tests
- `chore` - Maintenance, dependencies
- `build` - Build system changes
- `ci` - CI/CD configuration
- `revert` - Revert previous commit

### Subject Line Rules

- Use imperative mood: "Add feature" not "Added feature"
- Start with lowercase (no capital first letter)
- No period at end
- 50 characters maximum
- Be specific and descriptive

### Body Guidelines

- Explain WHAT and WHY, not HOW
- Wrap at 72 characters
- Use bullet points for multiple changes
- Reference issue numbers: `Fixes #123`
- Include breaking changes

### Examples

**Good:**
```bash
git commit -m "$(cat <<'EOF'
feat: add trading style filtering to history page

Implemented comprehensive search and filtering:
- Multi-criteria filtering (action, type, risk, style)
- Partial symbol search with case-insensitive matching
- LEFT JOIN with trading_styles table
- Extended API with new query parameters

Fixes #456
EOF
)"
```

**Bad:**
```bash
git commit -m "Fixed stuff"
git commit -m "WIP"
git commit -m "Updated files"
```

---

## Branching Strategy

### Branch Naming

**Format:** `type/description-in-kebab-case`

**Types:**
- `feature/` - New features
- `fix/` - Bug fixes
- `refactor/` - Code improvements
- `docs/` - Documentation
- `test/` - Test additions
- `chore/` - Maintenance

**Examples:**
```bash
feature/trading-style-personas
fix/history-filter-bug
refactor/database-queries
docs/api-documentation
```

### Branch Workflow

```bash
# Create and switch to new branch
git checkout -b feature/new-feature

# Work on changes
git add ...
git commit -m "..."

# Keep branch updated with main
git fetch origin
git rebase origin/main

# Push to remote
git push origin feature/new-feature

# Create pull request (via GitHub/GitLab UI)
```

### Branch Management

```bash
# List all branches
git branch -a

# Switch branches
git checkout branch-name

# Delete local branch
git branch -d branch-name

# Delete remote branch
git push origin --delete branch-name

# Rename current branch
git branch -m new-name
```

---

## Staging Operations

### Selective Staging

```bash
# Stage specific files
git add file1.ts file2.ts

# Stage entire directory
git add src/features/

# Stage all changes
git add .

# Stage by file extension
git add *.ts

# Interactive staging (patch mode)
git add -p file.ts
```

### Patch Mode Operations

When using `git add -p`:
- `y` - stage this hunk
- `n` - don't stage this hunk
- `s` - split into smaller hunks
- `e` - manually edit hunk
- `q` - quit
- `?` - help

### Unstaging

```bash
# Unstage all files
git reset HEAD

# Unstage specific file
git restore --staged file.ts

# Unstage directory
git restore --staged src/features/
```

---

## History Management

### Viewing History

```bash
# Compact history
git log --oneline -10

# Detailed history
git log -5

# With file changes
git log --stat -3

# Specific file history
git log -- path/to/file

# Graph view
git log --oneline --graph --all

# Search commits
git log --grep="search term"

# By author
git log --author="name"

# Date range
git log --since="2 weeks ago"
```

### Amending Commits

```bash
# Add forgotten files to last commit
git add forgotten-file.ts
git commit --amend --no-edit

# Change last commit message
git commit --amend -m "new message"
```

**⚠️ Warning:** Only amend commits that haven't been pushed!

### Interactive Rebase

```bash
# Rebase last 3 commits
git rebase -i HEAD~3

# Rebase from specific commit
git rebase -i commit-hash
```

**Options:**
- `pick` - keep commit as-is
- `reword` - change commit message
- `edit` - modify commit
- `squash` - combine with previous
- `fixup` - like squash, discard message
- `drop` - remove commit

### Squashing Commits

Before pushing:
```bash
# Squash last 3 commits
git rebase -i HEAD~3
# Mark commits as "squash" or "fixup"
```

### Cherry-picking

```bash
# Apply specific commit to current branch
git cherry-pick commit-hash

# Cherry-pick multiple commits
git cherry-pick hash1 hash2 hash3
```

---

## Merging & Rebasing

### Merge vs Rebase

**Merge:**
- Creates merge commit
- Preserves complete history
- Use for: integrating feature branches to main

```bash
git checkout main
git merge featur

Files: 1

Size: 15.4 KB

Complexity: 26/100

Category: Writing & Docs

Source: https://github.com/samhvw8/dot-claude/tree/main/skills/git-workflow

Related in Writing & Docs

jax-development

Included

Use this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.

Writing & Docsscripts

nature-article-writer

Included

Drafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.

Writing & Docsscripts

deckrd

Included

Document-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.

Writing & Docsscripts

clinical-decision-support

Included

Generate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.

Writing & Docsscripts

handling-sf-data

Included

Salesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).

Writing & Docsscripts

accelint-ac-to-playwright

Included

Convert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.

Writing & Docsscripts