Créer des commits Git de qualité

VérifiéSûr

Guide pour réviser, découper et committer des changements git avec des messages Conventionnels clairs et un staging sélectif.

Spar Skills Guide Bot
DeveloppementIntermédiaire
13/09/2026
Claude CodeCursorWindsurfCodex
#git#commits#conventional-commits#code-review#version-control

Recommandé pour

Synthèse automatique

Guide l'agent pour inspecter le répertoire de travail, isoler des commits logiquement distincts et rédiger des messages au format Conventional Commits.

Points forts

  • Applique une checklist ordonnée : status, diff, découpage, staging sélectif, relecture du diff indexé
  • Impose le staging par patch (git add -p) pour séparer les changements mixtes dans un même fichier
  • Intègre des contrôles de sûreté avant commit (secrets, logs de debug, bruit de formatage)
  • Exige une vérification minimale (test, lint ou build) avant de passer au commit suivant

Limites

  • Ne couvre pas la réécriture d'historique, le rebase, la signature ni la création de pull requests
  • Suppose que git add -p et git commit -v sont utilisables, ce qui peut être difficile en mode non interactif
  • Impose Conventional Commits sans proposer d'alternative si le dépôt suit un autre style
Quand l'utiliser

À utiliser quand l'utilisateur demande de committer, de rédiger un message de commit ou de découper son travail en plusieurs commits.

Quand l'éviter

À éviter pour des opérations sur l'historique existant (rebase, amend massif, revert) ou pour ouvrir une pull request.

Analyse de sécurité

Sûr
Score qualité86/100

The skill only instructs the agent to run standard read/stage git commands (git status, git diff, git add -p, git restore --staged, git diff --cached, git commit) and to sanity-check for secrets before committing. There is no network exfiltration, no destructive command (no rm -rf, no reset --hard, no force push), no base64 payloads, and no attempt to disable safety controls. The only marginally notable operation is `git restore --staged`, which unstages without touching working-tree content, so overall risk is minimal.

Aucun point d'attention détecté

Comment cette analyse est faite

Exemples

Commit current work
Review my working tree changes and commit them with a clear Conventional Commits message.
Split mixed changes
My changes mix a refactor and a new feature across several files — split them into separate logical commits with appropriate messages.
Message for staged diff
Look at what's staged with git diff --cached and write a Conventional Commits message with a body explaining what changed and why.

description: "Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits."

Commit work

Goal

Make commits that are easy to review and safe to ship:

  • only intended changes are included
  • commits are logically scoped (split when needed)
  • commit messages describe what changed and why

Inputs to ask for (if missing)

  • Single commit or multiple commits? (If unsure: default to multiple small commits when there are unrelated changes.)
  • Commit style: Conventional Commits are required.
  • Any rules: max subject length, required scopes.

Workflow (checklist)

  1. Inspect the working tree before staging
    • git status
    • git diff (unstaged)
    • If many changes: git diff --stat
  2. Decide commit boundaries (split if needed)
    • Split by: feature vs refactor, backend vs frontend, formatting vs logic, tests vs prod code, dependency bumps vs behavior changes.
    • If changes are mixed in one file, plan to use patch staging.
  3. Stage only what belongs in the next commit
    • Prefer patch staging for mixed changes: git add -p
    • To unstage a hunk/file: git restore --staged -p or git restore --staged <path>
  4. Review what will actually be committed
    • git diff --cached
    • Sanity checks:
      • no secrets or tokens
      • no accidental debug logging
      • no unrelated formatting churn
  5. Describe the staged change in 1-2 sentences (before writing the message)
    • "What changed?" + "Why?"
    • If you cannot describe it cleanly, the commit is probably too big or mixed; go back to step 2.
  6. Write the commit message
    • Use Conventional Commits (required):
      • type(scope): short summary
      • blank line
      • body (what/why, not implementation diary)
      • footer (BREAKING CHANGE) if needed
    • Prefer an editor for multi-line messages: git commit -v
    • Use references/commit-message-template.md if helpful.
  7. Run the smallest relevant verification
    • Run the repo's fastest meaningful check (unit tests, lint, or build) before moving on.
  8. Repeat for the next commit until the working tree is clean

Deliverable

Provide:

  • the final commit message(s)
  • a short summary per commit (what/why)
  • the commands used to stage/review (at minimum: git diff --cached, plus any tests run)

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/create-high-quality-git-commits-mtzb838s/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/create-high-quality-git-commits-mtzb838s' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/create-high-quality-git-commits-mtzb838s/download' --output '.skill-downloads/create-high-quality-git-commits-mtzb838s/SKILL.md.part' && mv '.skill-downloads/create-high-quality-git-commits-mtzb838s/SKILL.md.part' '.skill-downloads/create-high-quality-git-commits-mtzb838s/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.

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/create-high-quality-git-commits-mtzb838s/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