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
02/06/2026
Claude CodeCursorWindsurfCopilotCodex
#git#commit#push#version-control#safety-checks

Recommandé pour

Synthèse automatique

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.
Comment cette analyse est faite

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.

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/commit-and-push-everything-mm5t8ahv/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/commit-and-push-everything-mm5t8ahv' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/commit-and-push-everything-mm5t8ahv/download' --output '.skill-downloads/commit-and-push-everything-mm5t8ahv/SKILL.md.part' && mv '.skill-downloads/commit-and-push-everything-mm5t8ahv/SKILL.md.part' '.skill-downloads/commit-and-push-everything-mm5t8ahv/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Outils déclarés par l’auteur (à vérifier dans votre agent) : Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git push:*), Bash(git diff:*), Bash(git log:*), Bash(git pull:*)

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Le fichier ne fournit pas un en-tête name/description exploitable pour cette procédure native. Le téléchargement reste disponible pour lecture ; utilisez le mode manuel ci-dessous.

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/commit-and-push-everything-mm5t8ahv/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires