DEV Community: HereBuggedOut

Write a commit message for what you staged, not everything you edited

HereBuggedOut — Thu, 15 Oct 2026 20:50:51 +0000

Suppose you add a todo validation test and also tidy another test in the same file. You stage only the new test. A commit message describing both edits would promise a change that is not in the commit.

Agent Toolbox includes Good Commit, a reusable instruction file that asks an AI coding assistant to inspect the Git index before proposing a message. Here is a reproducible example using its small JavaScript demo.

Try it in a fresh clone

You need Git, Node.js to run the demo tests, and an assistant that can read files and run Git commands. No npm dependencies are required.

git clone https://github.com/zmo2s/agent-toolbox.git
cd agent-toolbox
git switch -c demo/partially-staged

Append this test to test/todo.test.js:

test("rejects an omitted title", () => {
  assert.throws(() => addTodo(), /Todo title is required/);
});

Stage that addition:

git add test/todo.test.js

Now rename the first test from creates a todo to creates an incomplete todo, but leave that rename unstaged. Both edits are in the same file, yet only the new test belongs to the next commit.

Inspect the two patches and run the tests:

git status --short
git diff --cached
git diff
npm test

The file should appear as MM test/todo.test.js: the first M represents staged changes, and the second represents unstaged changes. The cached diff should contain only the appended test; the ordinary diff should contain only the rename. Test counts can change as the project grows.

Ask for a message

Send your assistant this prompt from the clone:

Read .codex/skills/good-commit/SKILL.md and propose a commit message for my current changes.

An illustrative subject is:

test(core): ✅ cover omitted todo titles

The assistant should explain that this proposal covers the staged test addition and mention the unstaged test-name edit separately. It should not include that rename in the commit description, restage the entire file, or create a commit merely because you requested a message. Exact wording may vary; the important check is whether the message matches git diff --cached.

Reuse it in your project

Copy the Good Commit skill into .codex/skills/good-commit/SKILL.md in your repository and use the explicit prompt above. The /skill-commit shortcut additionally needs the routing instructions from AGENTS.md.

The skill provides instructions, not a guarantee of model behavior. Review the patch and proposed message before committing. You can try this workflow without installing the separate Security Guardian policy.

Help improve the examples

First-time contributors are welcome. Try documenting a breaking-change commit with migration guidance, or showing separate messages for unrelated changes. Check the issue and open PRs before starting, and follow the contribution guide.

Boostez votre productivité avec les hooks Git ! 🚀

HereBuggedOut — Sun, 09 Mar 2025 20:08:51 +0000

Chaque bug en production coûte cher et chaque erreur évitable fait perdre un temps précieux. Pourtant, il existe une solution simple pour automatiser les bonnes pratiques et garantir un code de qualité : les hooks Git.

Imaginez-les comme des arbitres de football ⚽, toujours attentifs à la moindre faute... ou plutôt, au moindre code douteux .

Pourquoi les Git hooks sont-ils comme les arbitres de football ?
Parce qu'ils sifflent les fautes, avant même que le ballon ne dépasse la ligne! 🥳

Les hooks Git permettent d’exécuter des scripts à différents moments du workflow Git pour prévenir les erreurs, assurer la cohérence du code et renforcer la sécurité.

🔹 Pre-commit : Vérifie et corrige le code avant qu’il ne soit validé.
🔹 Commit-msg : Applique un formatage strict aux messages de commit.
🔹 Pre-push : Exécute des tests et bloque le push si des erreurs sont détectées.

Avec ces hooks, vous pouvez automatiser les vérifications essentielles et garantir un code propre avant même qu'il n'atteigne votre dépôt distant.

💰 Bénéfices financiers

✅ Détection en amont des erreurs
Un hook pre-commit peut empêcher de committer du code qui ne compile pas ou qui contient des erreurs évidentes.

✅ Moins de corrections manuelles
Formatage automatique avec Prettier ou ESLint, suppression des espaces inutiles... un hook pre-commit peut éviter du travail répétitif.

✅ Cohérence du code
Un hook commit-msg peut imposer un format standardisé pour les messages de commit, rendant l’historique Git plus lisible et exploitable.

✅ Amélioration de la sécurité
Les hooks peuvent empêcher les commits accidentels contenant des informations sensibles comme des mots de passe ou clés API.

✅ Optimisation des pipelines CI/CD
Un hook pre-push peut exécuter des tests en local et bloquer un push si le build échoue, réduisant ainsi les exécutions inutiles de pipelines et les coûts associés

🛠️ Qualité du code et fiabilité

✅ Empêcher les commits de code cassé
Avec un hook pre-commit, vous évitez d’enregistrer du code non fonctionnel dans l’historique Git.

✅ Éviter les erreurs courantes
Un pre-commit peut supprimer automatiquement les console.log avant validation.

✅ Appliquer un formatage standard
Un hook commit-msg garantit que tous les messages de commit respectent une convention, comme Conventional Commits.

✅ Faciliter la collaboration
Les hooks assurent que tous les développeurs appliquent les mêmes règles automatiquement, évitant les oublis et les erreurs humaines.

🔥 Exemples pratiques

🛑 Filtrage des console.log

Un hook pre-commit peut détecter et bloquer les commits contenant des console.log, garantissant ainsi un code plus propre en production.

🎨 Application automatique du formatage du code

Un hook pre-commit peut s'exécuter un formateur comme Prettier ou ESLint pour corriger l’indentation et l’espacement avant chaque commit.

🔐 Empêcher l’exposition accidentelle de secrets

Un hook pre-commit ou pre-push peut scanner le code à la recherche de clés API ou de mots de passe en clair et empêcher leur commit.

🚧 Bloquer un push si le build échoue
Un hook pre-push peut être configuré pour exécuter des tests ou compiler le projet avant d’autoriser le push. Si le build échoue, le push est bloqué, empêchant ainsi du code cassé d’atteindre le dépôt distant.

Exemple de script dans un hook pre-push :

#!/bin/sh
echo "Exécution des vérifications pre-push..."

# Nettoyage et reconstruction du projet
dotnet clean
dotnet build

# Exécution des tests
dotnet test

if [ $? -ne 0 ]; then
    echo "Les tests ont échoué, push annulé."
    exit 1
fi

📺 Pour une explication détaillée, consultez cette vidéo :

Pour en savoir plus sur ESLint :
https://www.digitalocean.com/community/tutorials/linting-and-formatting-with-eslint-in-vs-code

🚀 Adoptez les hooks Git dès aujourd’hui !
Les hooks Git sont une solution simple mais puissante pour appliquer les bonnes pratiques, gagner du temps et réduire les coûts tout en améliorant la qualité et la sécurité du code.

En exploitant les hooks de manière efficace, les équipes de développement peuvent maintenir un workflow fluide et optimisé.