git-ghost : une IA locale pour relire l’historique Git
Découvrez git-ghost : Gemma analyse l’histoire d’un dépôt Git en local, sans API cloud, et transforme les commits en récit utile, avec ses limites.
Que raconterait votre premier commit à votre code actuel ?
Un dépôt Git conserve bien plus que l'état du code : il garde les traces des essais, des décisions et des compromis qui ont mené là où vous en êtes. Sauf qu'avec le temps, on ne revient pas à l'historique par plaisir. On y plonge surtout pour retrouver un changement précis. Du coup, les tout premiers commits finissent enterrés sous les corrections et les livraisons récentes.
git-ghost propose une autre façon de lire cette mémoire. Ce petit outil en ligne de commande prend les premiers et les derniers commits d'un dépôt, puis demande à Gemma, exécuté localement via Ollama, de « mettre des mots » sur le développeur d'hier et celui d'aujourd'hui. Ce n'est pas une analyse complète du code, ni un rapport d'ingénierie : c'est un récit court, construit à partir des messages de commit, avec une structure claire autour des débuts, de l'évolution du projet et d'un conseil concret.
Le concept est léger, presque ludique. Et pourtant, ça touche à des questions très concrètes : qu'est-ce qu'on peut vraiment inférer d'un historique Git ? Pourquoi choisir un modèle local ? Et, surtout, où est la limite de l'exercice ? Voici comment fonctionne git-ghost, et ce que ce cas d'usage dit (vraiment) sur les petits outils d'IA qui rendent service.
Que fait git-ghost avec l'historique Git ?
git-ghost est un outil en ligne de commande qui transforme une portion de l'historique d'un dépôt en une courte conversation fictive. Il ne cherche pas à « retrouver » la personnalité exacte de la personne qui a écrit le tout premier commit. En revanche, il donne une voix narrative à des traces réelles : les messages associés aux premiers changements et ceux des commits les plus récents.
Le récit suit une logique simple : « Je me souviens... » pour les débuts ; « Je vous vois maintenant... » pour ce que montrent les commits récents ; « Avant de disparaître... » pour un conseil bienveillant et concret. La métaphore du fantôme vient du thème du concours Hacktoberfest Open-Source AI Challenge, autour du « fantôme dans la machine ». En clair : au lieu d'empiler des logs, on tente d'en faire une histoire.
Pourquoi regarder les premiers et les derniers commits ?
Tout lire n'a pas toujours d'intérêt. Un projet actif peut cumuler des milliers de commits, avec une grosse part de petites corrections ou de changements internes. En opposant le début et la fin, git-ghost pose une question plus simple à aborder : qu'est-ce qui a changé depuis le départ ?
En pratique, ce contraste peut faire ressortir une évolution de périmètre, un changement de technologie, ou le passage d'un prototype à quelque chose de plus « produit ». Il peut aussi rappeler que les priorités actuelles n'ont rien à voir avec celles du tout début. Ce n'est pas une mesure rigoureuse de la trajectoire technique : c'est un point de départ pour relire l'historique.
Un usage léger, pas un audit de code
Et ça, il faut le dire clairement. D'après la description du projet, git-ghost s'appuie sur le journal des commits : il ne lit pas le dépôt en profondeur (fichiers, tickets, échanges d'équipe). Si les messages sont assez parlants, le modèle a de quoi raconter une évolution. S'ils se résument à « fix », « update » ou « ça marche », le récit restera forcément pauvre.
L'outil est donc plutôt fait pour explorer, tester une idée, ou faire une démonstration. Il peut donner une autre perspective sur un dépôt, mais il ne remplace ni une revue d'architecture, ni une documentation, ni une analyse sérieuse de l'historique pour décider quoi que ce soit en production.
Comment Gemma transforme-t-il les commits en récit ?
Le fonctionnement reste volontairement simple. Le programme récupère des informations avec git log, puis les envoie à un modèle Gemma exécuté localement par Ollama. La réponse s'affiche en flux dans le terminal, progressivement, au lieu d'être renvoyée en bloc à la fin.
Le projet tient dans un seul fichier Python. Il utilise la bibliothèque standard : subprocess pour appeler Git, et urllib pour parler au point d'accès local d'Ollama. Pas de dépendances Python externes à ajouter. Par défaut, le modèle est gemma3:4b, mais le paramètre --model permet d'en choisir un autre géré par votre installation d'Ollama.
Le prompt sert de garde-fou
Un modèle de langage ne fait pas que restituer ce qu'on lui donne. Il peut combler les zones manquantes, relier des éléments, ou produire une explication « plausible » qui n'est pas forcément vraie. Pour une lecture d'historique, c'est exactement le risque : un texte fluide peut donner l'impression que le modèle a « vu » le code, alors qu'il n'a eu que des messages de commit.
Le prompt système de git-ghost essaie donc de limiter l'invention en demandant de s'en tenir aux faits contenus dans l'historique transmis. Utile, oui. Mais ce n'est pas une garantie mathématique : le modèle peut mal interpréter un message ambigu ou surestimer un détail. Il faut lire le résultat comme une interprétation, pas comme une vérité certifiée.
Une architecture adaptée à un outil personnel
Pour un outil personnel, miser sur la simplicité est logique. Pas de service à déployer, pas de clé API à gérer, pas de base de données, ni de chaîne de traitement complexe. Tout tient en trois étapes : lire les commits, construire la demande, afficher la réponse.
Le projet inclut aussi un test unitaire qui démarre un faux serveur Ollama et un dépôt Git temporaire. Objectif : vérifier le comportement du programme sans télécharger de modèle et sans dépendre d'une génération réelle. Les tests valident la logique ; le modèle, lui, reste une dépendance d'exécution.
Cela dit, « pas de dépendances Python » ne veut pas dire « zéro prérequis ». Il faut Git, Python et Ollama, plus un modèle local compatible. La génération consomme des ressources, et la qualité dépend à la fois des capacités du modèle et de la qualité des messages transmis.
Pourquoi faire tourner cette IA en local ?
Un historique de code peut contenir des noms de clients, des détails d'infrastructure, des noms de branches révélateurs, ou des éléments liés à un produit encore non publié. Dans ce contexte, envoyer ces données à une API externe pour obtenir un texte un peu nostalgique n'est pas forcément le meilleur compromis. L'intérêt du modèle local est clair : le traitement peut se faire sur votre machine, sans transmettre le journal à un service cloud.
Il y a aussi un côté pratique : moins de coûts opérationnels (pas de facturation par requête) et pas de clé d'API à distribuer. Quand l'outil n'est utilisé qu'occasionnellement, la simplicité pèse autant que le prix. Et vous pouvez tester sur un dépôt personnel sans créer de compte sur un service distant.
Local ne veut pas automatiquement dire « confidentiel »
Mais attention au raccourci. « Local » ne garantit pas la sécurité à lui seul. Tout dépend de votre configuration réelle : où écoute Ollama ? Le poste est-il bien administré ? Le modèle et les journaux sont-ils accessibles à d'autres utilisateurs ? Certains outils de supervision enregistrent-ils les requêtes ?
En entreprise, ces points comptent même si, sur un projet perso, ils peuvent sembler un peu obsessionnels. Mieux vaut vérifier le chemin des données plutôt que se fier à l'étiquette « IA locale ». Il faut notamment s'assurer que le modèle tourne bien sur l'environnement prévu, que les données ne transitent pas vers un service distant, et que les règles internes autorisent le traitement de l'historique concerné. Le RGPD n'est pas le seul sujet : la confidentialité contractuelle et la propriété intellectuelle peuvent aussi entrer en jeu.
Un cas d'usage qui n'exige pas une plateforme entière
L'intérêt de git-ghost, c'est aussi sa taille. Tous les usages de l'IA ne nécessitent pas un système d'entreprise, une interface dédiée, ou un assistant intégré partout. Pour une lecture ponctuelle, un script lisible et modifiable peut largement suffire.
Cette approche est pertinente si le coût de mise en œuvre doit rester bas, si les données ne doivent pas sortir du poste, et si une réponse imparfaite est acceptable parce qu'elle sert à réfléchir plutôt qu'à automatiser une décision. Ça marche moins bien si une équipe attend des résumés vérifiables, une couverture exhaustive de tous les changements, ou une intégration solide dans le processus de livraison.
Quelles sont les limites et les précautions à prévoir ?
Le premier facteur de qualité, ce n'est pas le modèle : c'est l'historique. Des messages de commit cohérents donnent au récit des repères utilisables. À l'inverse, un dépôt avec des messages vagues, des commits « regroupés », ou des réécritures rend l'interprétation plus fragile. Beaucoup de projets ne sont pas tenus comme des journaux destinés à raconter l'évolution d'un produit : ils servent d'abord à versionner le code.
Deuxième point : le périmètre des données. Les messages de commit ne racontent pas toute l'histoire. Ils n'expliquent pas forcément pourquoi une décision a été prise, quels retours utilisateurs ont influencé le choix, ni quelles contraintes commerciales ont poussé à changer de cap. Le modèle peut faire émerger une lecture intéressante, mais il ne peut pas reconstruire ce qui n'a jamais été consigné.
Une réponse bien écrite peut rester fausse
La forme narrative est à la fois la force et le risque. En personnifiant le passé, git-ghost rend l'historique plus accrocheur. Mais le texte fluide peut aussi masquer l'incertitude. Un conseil formulé avec chaleur n'est pas pour autant un conseil juste.
Pour garder une lecture saine, vérifiez les éléments factuels cités : noms de fonctionnalités, séquence des changements, évolution décrite. Si une phrase prête une intention que les commits ne montrent pas clairement, considérez-la comme une invention (ou du moins une extrapolation) du modèle. Et si c'est utilisé en atelier d'équipe, faites distinguer ce que l'historique prouve de ce que le récit suggère.
Quand l'utiliser, et quand choisir autre chose ?
git-ghost est adapté à une démonstration, à un dépôt personnel, ou à une rétrospective informelle. Il peut fournir une entrée ludique dans l'histoire d'un projet, par exemple pendant une session de partage ou un événement communautaire. En revanche, ce n'est pas fait pour servir de source unique afin de documenter un système, évaluer une équipe, ou justifier une décision technique.
Avant de l'adopter, posez-vous quatre questions :
- Les commits contiennent-ils assez de contexte ? Sinon, le modèle aura peu de matière fiable.
- Le dépôt peut-il être traité localement sur votre environnement ? Regardez la configuration, pas seulement le nom de l'outil.
- Le résultat sert-il à explorer ou à décider ? Pour décider, il faut des sources vérifiables et une validation humaine.
- Le gain vaut-il l'installation du modèle ? Pour une lecture ponctuelle, la préparation peut prendre plus de temps que l'usage.
Si votre besoin réel est de comprendre précisément pourquoi une architecture a changé, vous aurez souvent plus de résultats avec de la documentation tenue à jour, des décisions d'architecture explicites, ou une revue humaine de l'historique. Un modèle peut ouvrir la discussion ; il ne remplace pas les traces qui manquent.