Flux de travail Git

VérifiéPrudence

Opérations Git et workflow de pull request. Créez des PR, rebasez des branches, résolvez des conflits et fusionnez avec rebase. Utile lorsque vous devez créer une PR ou travailler avec des branches et un dépôt amont.

Spar Skills Guide Bot
DeveloppementIntermédiaire
9002/06/2026
Claude Code
#git#pull-requests#rebase#workflow#collaboration

Recommandé pour

Notre avis

Gère les opérations Git avancées comme la création de pull requests, le rebasage et la résolution de conflits pour contribuer à des dépôts upstream.

Points forts

  • Automatise la mise à jour et le rebasage avant la création de PR
  • Gère à la fois les forks et les branches directes sur le dépôt principal
  • Intègre la résolution de conflits avec des instructions claires

Limites

  • Nécessite que l'utilisateur ait configuré les remotes upstream et origin
  • Les conflits de rebasage complexes peuvent nécessiter une intervention manuelle
  • Suppose que les modifications sont déjà commitées localement
Quand l'utiliser

Quand vous devez créer une pull request sur un dépôt upstream après avoir travaillé sur une branche ou un fork.

Quand l'éviter

Pour des commits simples sur la branche principale d'un dépôt personnel sans besoin de PR.

Analyse de sécurité

Prudence
Score qualité88/100

The skill describes a standard git collaboration workflow including branching, rebasing, pushing, and creating pull requests. While the commands themselves are not destructive or obfuscated, they involve network operations (git push, fetch) that could potentially expose data if the remote is malicious, and force push with lease can overwrite remote branches. The skill includes a guardrail to wait for user confirmation before pushing or creating PRs, reducing risk.

Points d'attention
  • Uses git push with --force-with-lease, which can overwrite remote history if misapplied.
  • Instructs reading configuration from a local file (.claude-workspace), but no exfiltration risk.

Exemples

Create a PR from a fork
Create a pull request from my fork to the upstream repository for the pattern I just committed.
Rebase feature branch before PR
Update my current branch with the latest changes from upstream main and rebase before creating a pull request.

name: git-workflow description: > Git operations and pull request workflows. Create PRs, rebase branches, resolve conflicts, merge to upstream. Use when ready to create PR or when working with git branches and upstream.

Git Workflow

Committing Work

cd ~/Code/community-patterns

git add patterns/$GITHUB_USER/pattern.tsx
git commit -m "Add pattern: description"
git push origin main

Getting Updates (Already done in Step 1)

git fetch upstream
git pull --rebase upstream main
git push origin main

Sharing Work Upstream (Creating Pull Requests)

IMPORTANT: Wait for user to tell you to create a PR. Don't push or create PRs automatically.

Before creating any PR, you MUST update from main and rebase your branch:

Step 0: Update and Rebase Before Creating PR

Use cached repository type from workspace config:

# Read IS_FORK from .claude-workspace (set during Step 2)
IS_FORK=$(grep "^is_fork=" .claude-workspace | cut -d= -f2)

# Determine which remote to use
if [ "$IS_FORK" = "true" ]; then
  echo "Working on fork - will fetch from upstream"
  MAIN_REMOTE="upstream"
else
  echo "Working on main repo - will fetch from origin"
  MAIN_REMOTE="origin"
fi

Then fetch latest main and rebase your branch:

# Fetch latest main
git fetch $MAIN_REMOTE

# Rebase current branch on top of main
git rebase $MAIN_REMOTE/main

# If rebase succeeds, push (force-with-lease if on feature branch)
if [ "$(git branch --show-current)" != "main" ]; then
  git push origin $(git branch --show-current) --force-with-lease
else
  git push origin main
fi

If rebase has conflicts:

  1. Show conflict files: git status
  2. Help resolve conflicts
  3. Continue: git rebase --continue
  4. Then push

Why this matters:

  • Ensures your PR is based on the latest main
  • Avoids merge conflicts during PR review
  • Makes PR review easier

If User Has Their Own Fork (Most Common)

When user wants to contribute patterns from their fork to upstream:

Step 1: Ensure changes are committed and pushed to their fork

cd ~/Code/community-patterns
git status  # Verify all changes are committed
git push origin main

Step 2: Update and rebase (see Step 0 above)

Step 3: Create pull request to upstream

gh pr create \
  --repo jkomoros/community-patterns \
  --title "Add: pattern name" \
  --body "$(cat <<'EOF'
## Summary
- Brief description of the pattern
- Key features
- Use cases

## Testing
- [x] Pattern compiles without errors
- [x] Tested in browser at http://localhost:8000
- [x] All features working as expected

🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

If Working Directly on jkomoros/community-patterns

CRITICAL: When working directly on the upstream repository, you MUST use branches and PRs. Direct pushes to main are NOT allowed.

Step 1: Create feature branch

cd ~/Code/community-patterns
git checkout -b username/feature-name

Step 2: Commit and push branch

git add patterns/$GITHUB_USER/
git commit -m "Add: pattern name"
git push origin username/feature-name

Step 3: Update and rebase (see Step 0 above)

Step 4: Create pull request

gh pr create \
  --title "Add: pattern name" \
  --body "$(cat <<'EOF'
## Summary
- Brief description

## Testing
- [x] Tested and working

🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

Step 5: Merge with rebase (when approved)

gh pr merge PR_NUMBER --rebase --delete-branch

Important Notes

  • Always wait for user permission before creating PRs
  • All PRs are merged with --rebase (NOT --squash or --merge)
  • This preserves individual commit history
  • Commit frequently locally, but only create PR when user asks
  • PRs will be reviewed before merging to upstream
  • After merge, everyone gets your patterns automatically on next update
Skills similaires