Valider et pousser tous les changements

VérifiéPrudence

Automatise l'ajout, le commit et le push de toutes les modifications d'un dépôt Git, avec des vérifications de sécurité préalables (fichiers sensibles, API keys, gros fichiers). Idéal pour une mise à jour rapide et globale quand on est sûr de la cohérence des changements, mais nécessite une confirmation explicite avant exécution.

Spar Skills Guide Bot
DeveloppementIntermédiaire
5002/06/2026
Claude CodeCursorWindsurfCopilotCodex
#git#commit#push#version-control#safety-checks

Recommandé pour

Notre avis

Automatise l'ajout, le commit et le push de tous les changements après des vérifications de sécurité et confirmation de l'utilisateur.

Points forts

  • Automatise tout le flux de commit et push en une seule commande.
  • Inclut des vérifications de sécurité pour les secrets, gros fichiers et artefacts de build.
  • Génère un message de commit conventionnel basé sur les modifications détectées.
  • Exige une confirmation explicite avant d'exécuter les actions.

Limites

  • Commit tous les changements en une fois, non adapté pour des commits granulaires.
  • Dépend de la vigilance de l'utilisateur pour les vérifications de sécurité.
  • Ne fonctionne qu'avec des dépôts Git classiques.
Quand l'utiliser

Lorsque vous êtes certain que tous les changements non commités forment un ensemble cohérent et que vous souhaitez un commit et push rapide avec des garde-fous automatiques.

Quand l'éviter

Lorsque vous avez besoin de staging sélectif, quand vous travaillez sur une branche protégée nécessitant des pull requests, ou si des secrets ou fichiers volumineux ne doivent pas être commités.

Analyse de sécurité

Prudence
Score qualité88/100

The skill uses only git commands (safe in themselves) but orchestrates a powerful action: committing and pushing all unstaged changes. It includes security checks for secrets, large files, and artifacts, and requires explicit confirmation, reducing but not eliminating the risk of accidental exposure. No network exfiltration or destructive system commands are present.

Points d'attention
  • Automates staging and pushing all changes, which could accidentally push sensitive data if the user bypasses warnings.
  • Relies entirely on user confirmation; a careless 'yes' could still result in exposure.

Exemples

Commit and push everything
I'm sure, commit and push all my changes with a meaningful commit message.
Stage all and push with safety
Run the commit and push workflow, but make sure to check for secrets first.

description: Stage all changes, create commit, and push to remote (use with caution) allowed-tools: Bash(git add:), Bash(git status:), Bash(git commit:), Bash(git push:), Bash(git diff:), Bash(git log:), Bash(git pull:*)

Commit and Push Everything

⚠️ CAUTION: Stage ALL changes, commit, and push to remote. Use only when confident all changes belong together.

Workflow

1. Analyze Changes

Run in parallel:

  • git status - Show modified/added/deleted/untracked files
  • git diff --stat - Show change statistics
  • git log -1 --oneline - Show recent commit for message style

2. Safety Checks

❌ STOP and WARN if detected:

  • Secrets: .env*, *.key, *.pem, credentials.json, secrets.yaml, id_rsa, *.p12, *.pfx, *.cer
  • API Keys: Any *_API_KEY, *_SECRET, *_TOKEN variables with real values (not placeholders like your-api-key, xxx, placeholder)
  • Large files: >10MB without Git LFS
  • Build artifacts: node_modules/, dist/, build/, __pycache__/, *.pyc, .venv/
  • Temp files: .DS_Store, thumbs.db, *.swp, *.tmp

API Key Validation: Check modified files for patterns like:

OPENAI_API_KEY=sk-proj-xxxxx  # ❌ Real key detected!
AWS_SECRET_KEY=AKIA...         # ❌ Real key detected!
STRIPE_API_KEY=sk_live_...    # ❌ Real key detected!

# ✅ Acceptable placeholders:
API_KEY=your-api-key-here
SECRET_KEY=placeholder
TOKEN=xxx
API_KEY=<your-key>
SECRET=${YOUR_SECRET}

✅ Verify:

  • .gitignore properly configured
  • No merge conflicts
  • Correct branch (warn if main/master)
  • API keys are placeholders only

3. Request Confirmation

Present summary:

📊 Changes Summary:
- X files modified, Y added, Z deleted
- Total: +AAA insertions, -BBB deletions

🔒 Safety: ✅ No secrets | ✅ No large files | ⚠️ [warnings]
🌿 Branch: [name] → origin/[name]

I will: git add . → commit → push

Type 'yes' to proceed or 'no' to cancel.

WAIT for explicit "yes" before proceeding.

4. Execute (After Confirmation)

Run sequentially:

git add .
git status  # Verify staging

5. Generate Commit Message

Analyze changes and create conventional commit:

Format:

[type]: Brief summary (max 72 characters)

- Key change 1
- Key change 2
- Key change 3

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

Example:

docs: Update concept README files with comprehensive documentation

- Add architecture diagrams and tables
- Include practical examples
- Expand best practices sections

6. Commit and Push

git commit -m "$(cat <<'EOF'
[Generated commit message]
EOF
)"
git push  # If fails: git pull --rebase && git push
git log -1 --oneline --decorate  # Verify

7. Confirm Success

✅ Successfully pushed to remote!

Commit: [hash] [message]
Branch: [branch] → origin/[branch]
Files changed: X (+insertions, -deletions)

Error Handling

  • git add fails: Check permissions, locked files, verify repo initialized
  • git commit fails: Fix pre-commit hooks, check git config (user.name/email)
  • git push fails:
    • Non-fast-forward: git pull --rebase && git push
    • No remote branch: git push -u origin [branch]
    • Protected branch: Use PR workflow instead

When to Use

Good:

  • Multi-file documentation updates
  • Feature with tests and docs
  • Bug fixes across files
  • Project-wide formatting/refactoring
  • Configuration changes

Avoid:

  • Uncertain what's being committed
  • Contains secrets/sensitive data
  • Protected branches without review
  • Merge conflicts present
  • Want granular commit history
  • Pre-commit hooks failing

Alternatives

If user wants control, suggest:

  1. Selective staging: Review/stage specific files
  2. Interactive staging: git add -p for patch selection
  3. PR workflow: Create branch → push → PR (use /pr command)

⚠️ Remember: Always review changes before pushing. When in doubt, use individual git commands for more control.

Skills similaires