agentsclimarketplace

Git workflow

Skill medy-gribkov/arcana/skills/git-workflow

Universal AI development toolkit. 74 production-ready skills for every coding agent. Works with Claude Code, Cursor, Codex.

Install
npx -y skills add medy-gribkov/arcana --skill git-workflow

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Git workflow automation with conventional commits, merge vs rebase decision trees, worktrees, SSH signing, and monorepo sparse checkout patterns.

SKILL.md

8.6 KB, ~2.3k tokens by cl100k_base, as published. Nobody here has run it

Conventional Commit Format

# BAD: vague, no type
git commit -m "changes"

# GOOD: clear type, scope, imperative mood
git commit -m "feat(auth): add OAuth2 login flow"
git commit -m "fix(api): handle null response in getUserData"
git commit -m "docs(readme): update installation steps"

Format: type(scope): description

Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore

Breaking changes:

git commit -m "feat(api)!: remove deprecated v1 endpoints"
# Or in body:
git commit -m "feat(api): migrate to v2 endpoints

BREAKING CHANGE: v1 endpoints removed, use v2"

Setup Commit Linting

# Install commitlint
npm install --save-dev @commitlint/config-conventional @commitlint/cli

# Create config
cat > commitlint.config.js <<'EOF'
module.exports = { extends: ['@commitlint/config-conventional'] };
EOF

# Hook with Husky
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit $1'

Merge vs Rebase Decision Tree

Question: Is the branch shared with others?
│
├─ YES → USE MERGE
│   └─ git merge feature-branch
│      (preserves branch history, safer for collaboration)
│
└─ NO → Ask: Do you want linear history?
    │
    ├─ YES → USE REBASE
    │   └─ git rebase main
    │      (clean history, better for bisect)
    │
    └─ NO → USE MERGE
        └─ git merge --no-ff feature-branch
           (preserves feature branch context)

Rebase workflow for feature branches:

# Daily sync (before starting work)
git checkout feature-branch
git fetch origin
git rebase origin/main

# Interactive cleanup before PR
git rebase -i origin/main
# Squash "fix typo", "wip" commits

# After PR approval
git checkout main
git merge --ff-only feature-branch  # or squash in GitHub UI

When rebase conflicts occur:

# BAD: panic and force push to main
git push --force origin main  # NEVER DO THIS

# GOOD: resolve, test, continue
git rebase main
# Fix conflicts in files
git add resolved-file.js
git rebase --continue
npm test  # Always test after resolving
git push --force-with-lease origin feature-branch

Abort and recover:

# Rebase went wrong? Abort it
git rebase --abort

# Already committed a bad rebase? Find previous state
git reflog
# Outputs: abc123 HEAD@{1}: rebase finished
#          def456 HEAD@{2}: checkout: moving from main to feature
git reset --hard def456  # Go back before rebase

Git Worktrees (Multiple Branches Simultaneously)

# BAD: stashing and switching repeatedly
git stash
git checkout hotfix-branch
# fix bug
git checkout main
git stash pop

# GOOD: use worktrees
git worktree add ../myproject-hotfix hotfix-branch
cd ../myproject-hotfix
# work on hotfix while main branch untouched in ../myproject

# List all worktrees
git worktree list

# Remove when done
git worktree remove ../myproject-hotfix

Use case: review PR while keeping main branch clean:

git worktree add ../myproject-pr-review pr/123
cd ../myproject-pr-review
npm install
npm test
# Review done
cd ../myproject
git worktree remove ../myproject-pr-review

SSH Commit Signing Setup

# Generate signing key (Ed25519)
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/git_signing

# Add public key to GitHub: Settings → SSH and GPG keys → New SSH key
# Paste contents of ~/.ssh/git_signing.pub, select "Signing Key"

# Configure git to use SSH signing
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/git_signing.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

# Test it
git commit --allow-empty -m "test: verify SSH signing"
git log --show-signature
# Should show: "Good signature with ED25519 key..."

Per-repository signing:

cd my-project
git config user.signingkey ~/.ssh/git_signing_work.pub  # Different key for work

Monorepo with Sparse Checkout

Problem: Monorepo with 50 packages, you only work on 2.

# BAD: clone entire 5GB repo
git clone https://github.com/company/monorepo.git
# Downloads 5GB, slow npm install across all packages

# GOOD: sparse checkout
git clone --filter=blob:none --sparse https://github.com/company/monorepo.git
cd monorepo
git sparse-checkout init --cone
git sparse-checkout set packages/frontend packages/api

# Only these directories are checked out:
# packages/frontend/
# packages/api/
# Root files (package.json, etc.)

Add more packages later:

git sparse-checkout add packages/shared-ui

Full monorepo strategy:

# 1. Initialize sparse checkout
git clone --filter=blob:none --sparse https://github.com/company/monorepo.git
cd monorepo

# 2. Set up workspace
git sparse-checkout set packages/my-app libs/shared-utils

# 3. Install dependencies (only for checked out packages)
npm install  # or pnpm/yarn

# 4. Configure CODEOWNERS (in repo root)
cat > .github/CODEOWNERS <<'EOF'
/packages/frontend/ @frontend-team
/packages/api/ @backend-team
/libs/shared-utils/ @platform-team
EOF

# 5. Tag releases per package
git tag @company/[email protected]
git tag @company/[email protected]
git push origin --tags

Merge Conflict Resolution

# List conflicted files
git diff --name-only --diff-filter=U

# BAD: manually edit without understanding
vim conflicted.js  # Hope for the best

# GOOD: use strategy for simple conflicts
git checkout --theirs package-lock.json  # Take their version
git checkout --ours config/local.json    # Keep our version
git add package-lock.json config/local.json

# For complex conflicts, use mergetool
git mergetool --tool=vimdiff  # or meld, kdiff3, vscode

Test after every conflict resolution:

git rebase --continue
npm test || (git rebase --abort && echo "Tests failed, fix conflicts")

Git Hooks with Lefthook

# Install lefthook (faster, polyglot alternative to Husky)
go install github.com/evilmartians/lefthook@latest
# Or: npm install lefthook --save-dev

# Create lefthook.yml
cat > lefthook.yml <<'EOF'
pre-commit:
  parallel: true
  commands:
    lint:
      glob: "*.{js,ts}"
      run: eslint --fix {staged_files}
    format:
      glob: "*.{js,ts,json,md}"
      run: prettier --write {staged_files}
    types:
      glob: "*.{ts,tsx}"
      run: tsc --noEmit

commit-msg:
  commands:
    commitlint:
      run: npx commitlint --edit {1}

pre-push:
  commands:
    test:
      run: npm test
    check-secrets:
      run: gitleaks detect --no-git --verbose
EOF

# Install hooks
lefthook install

Branch Strategies

Trunk-Based Development (Recommended)

# 1. Create short-lived feature branch
git checkout -b feat/user-profile

# 2. Work in small increments (1-2 days max)
git commit -m "feat(profile): add avatar upload"
git commit -m "test(profile): add avatar validation tests"

# 3. Rebase daily
git fetch origin
git rebase origin/main

# 4. Open PR when ready (same day or next day)
gh pr create --title "Add user profile avatar upload"

# 5. Squash merge to main
gh pr merge --squash

Git Flow (Complex Release Cycles)

# Long-lived branches: main, develop
# Supporting: feature/*, release/*, hotfix/*

# Start feature
git checkout develop
git checkout -b feature/payment-integration

# Finish feature
git checkout develop
git merge --no-ff feature/payment-integration
git branch -d feature/payment-integration

# Create release branch
git checkout -b release/1.2.0 develop
# Fix bugs in release/1.2.0

# Merge to main and develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release v1.2.0"
git checkout develop
git merge --no-ff release/1.2.0
git branch -d release/1.2.0

Only use Git Flow if:

  • Multiple versions in production (e.g., SaaS with customer-specific deployments)
  • Regulated industry requiring formal release process
  • Large team (50+) with parallel release tracks

Troubleshooting

# Lost commits after reset
git reflog
git cherry-pick abc123  # Restore lost commit

# Committed to wrong branch
git log  # Copy commit hash
git checkout correct-branch
git cherry-pick abc123
git checkout wrong-branch
git reset --hard HEAD~1  # Remove from wrong branch

# Remove file from history (leaked secret)
git filter-repo --path secrets.env --invert-paths
# Note: force push required, coordinate with team

# Undo last commit (keep changes staged)
git reset --soft HEAD~1

# Undo last commit (keep changes unstaged)
git reset HEAD~1

# Undo last commit (discard changes - CAREFUL)
git reset --hard HEAD~1

Gives 1 of the 12 instructions most pr commit review skills give in ~2.3k tokens

Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-07

  • use conventional commits formathere, and in 127 of 888, across 115 files
  • keep subject line under 72 charactersin 62 of 888, across 48 files
  • delete branches after mergein 51 of 888, across 38 files
  • use imperative mood in subject linein 51 of 888, across 42 files
  • use imperative mood in commit messagesin 44 of 888
  • verify directory is ignored before creating worktreein 43 of 888, across 12 files
  • generate a conventional commit messagein 43 of 888
  • add unignored worktree directories to gitignorein 42 of 888, across 10 files
  • make atomic commitsin 39 of 888, across 27 files
  • run tests before committingin 36 of 888, across 25 files
  • verify clean test baselinein 35 of 888, across 9 files
  • split unrelated changes into separate commitsin 35 of 888, across 30 files

Said here and by no other author read

  • install git hooks using lefthook

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.