Si votre équipe utilise les Conventional Commits, vous connaissez sans doute le problème. Le format s'apprend en cinq minutes, mais le choix du type reste une affaire d'interprétation. Corriger un bug en réécrivant la fonction, est-ce un fix ou un refactor ? Une montée de dépendance, un build ou un chore ? Chacun répond à sa manière, et les linters ne sont d'aucun secours, puisqu'ils vérifient la syntaxe du message sans regarder le contenu du changement. Au bout de quelques mois, le changelog raconte une histoire approximative et les releases automatiques calculent des numéros de version à partir de types choisis à l'instinct.

J'ai fini par me dire que la seule source fiable était le diff lui-même. Comme j’aime bien m’amuser à monter des modèles IA, j'ai écrit git guess pour résoudre ce problème.

Pourquoi je l'ai fait ?

Il existe déjà beaucoup d'outils qui écrivent des messages de commit. La plupart envoient votre diff à un LLM hébergé dans le cloud, ce qui suppose de transmettre votre code à un tiers, y compris ce qui n'est pas encore commité, et de gérer une clé d'API pour un simple préfixe de message. Je n'en avais pas envie.

J'ai donc pris le chemin inverse et construit un outil souverain, qui ne dépend d'aucune IA externe. Le modèle est embarqué dans le binaire, tout tourne en local et rien ne quitte votre machine. Je le voulais aussi très simple à adopter, avec un seul binaire (écrit en Go), sans dépendance, sans compte et sans configuration. Enfin je le voulais rapide, parce qu'une commande qui s'intercale dans git commit n'a pas le droit de se faire remarquer. La réponse tombe en une trentaine de millisecondes.

Comment ça marche ?

Le modèle a été entraîné sur 488 000 commits provenant de 244 projets open source, qui lui donnent sa culture générale. Il apprend ensuite des 1 000 derniers commits de votre dépôt, qui lui apportent la culture de votre équipe. Si chez vous les migrations partent en chore, git guess les classera en chore au lieu d'imposer sa propre vision. Concrètement, il lit le diff, le compare à ce qu'il connaît et propose un type accompagné d'un score de confiance.

git guess                      # que contiennent mes changements indexés ?

git guess -m "add login"       # feat(auth): add login

git guess HEAD~1               # un commit, ou une plage main..feature

git guess eval                 # quelle précision sur mon propre historique ?

Au passage, ça supporte également les gitmoji.

Au quotidien

Mon mode d'utilisation préféré reste le hook, qui s'installe en une commande :

git guess hook install

À partir de là, l'outil se fait oublier. Un git commit -m "add login" devient feat(auth): add login, et un git commit sans argument ouvre votre éditeur avec le type déjà rempli. Quand la décision est serrée, une seule question s'affiche, du genre ? fix 41% or refactor 38%? [f/r], et vous y répondez d'une touche. J'ai aussi posé une règle stricte dès la conception : le hook ne bloque jamais un commit, parce qu'un outil qui se met en travers d'un correctif urgent finit désinstallé avant la fin de la semaine.

En intégration continue, une action GitHub reprend le même moteur pour étiqueter vos pull requests à partir de leur diff et vérifier les commits d'une branche. Une ligne suffit : uses: Halleck45/git-guess@v1.

Est-ce que ça marche vraiment ?

Sur des dépôts que le modèle n'a jamais vu, j'obtiens 70 % de bonnes réponses au premier choix et 88 % dans les deux premiers. C’est, je crois, suffisant, d’autant que je voulais garder le modèle simple et léger. La commande git guess eval rejoue l'historique de votre dépôt et mesure combien de fois l'outil aurait retrouvé le type que votre équipe avait réellement choisi, ce qui vous permet de juger sur votre propre code avant d'adopter quoi que ce soit. J'ai d'ailleurs remarqué que les cas où l'outil hésite sont presque toujours ceux où l'équipe hésitait déjà.

Installation

brew install Halleck45/tap/git-guess

# ou

curl -fsSL https://raw.githubusercontent.com/Halleck45/git-guess/main/install.sh | sh

# ou

npx git-guess

Des binaires sont disponibles pour Linux, macOS et Windows (amd64, arm64) sur la page des releases, et le projet est publié sous licence MIT. Le projet est tout jeune, et le meilleur moyen de m'aider est de le tester sur vos dépôts, puis de me dire ce que git guess eval vous raconte. Les retours, bons ou mauvais, sont ce qui fait vivre un outil open source.

Dépôt : https://github.com/Halleck45/git-guess
Documentation : https://halleck45.github.io/git-guess/