Gitnetix

Gitnetix est un client Git construit autour des versions, avec l’IA intégrée. Le moteur est en Rust, l’interface en React, et Tauri 2 réunit les deux dans une app de bureau pour Linux, macOS et Windows. La même interface existe aussi en app mobile qui pilote l’ordinateur à distance.

Un arbre, pas un graphe

La plupart des clients Git dessinent le graphe des commits : des rails colorés, des fusions qui se croisent, des centaines de points. Il montre ce que Git a stocké, pas ce sur quoi on travaille. Gitnetix n’a pas de graphe de commits. Il montre les branches en arbre : main en haut, les versions en dessous, les fonctionnalités et les correctifs sous leur version. On voit son travail, pas ses commits.

• Le chemin orange. La branche extraite reçoit un chemin lumineux tracé depuis main jusqu’à elle, parcouru par une pulsation, et les branches qu’il ne fait que longer sont atténuées. D’un coup d’œil, on sait où on est et dans quoi on va fusionner.
• Fusionnées : le travail terminé se range tout seul, même après une PR fusionnée par squash.
• Livrées : les versions publiées sont mises à part avec leur tag. On supprime le tag, et la version se rouvre.
• En retard : les branches laissées à l’abandon sont regroupées, et se nettoient en un clic.

Le flux de travail

• Les versions d’abord. Une version est une branche release/x.y.z créée depuis main (ou depuis le dernier tag pour un correctif urgent). Les fonctionnalités et les correctifs en partent, sur place ou dans leur propre worktree.
• Des agents en parallèle. Un agent IA (Claude Code, Codex, Gemini…) peut travailler sur chaque branche en même temps, chacun dans son worktree, et sa session continue quand on change de projet.
• Livrer. Une seule action date la section Unreleased du CHANGELOG.md, avance main jusqu’à la branche de version, pose le tag vx.y.z et peut pousser les deux.
• L’IA là où elle fait gagner du temps. Messages de commit, noms de branches, descriptions de PR, notes de version, mise à jour du changelog, résolution de conflits et tri des tickets, le tout guidé par des gabarits modifiables et un modèle choisi par tâche : un modèle léger pour les messages de commit, un plus costaud là où ça compte.

Ce que ça fait

• Espace de travail : l’arbre des branches, des listes de commits qui montrent le local et l’origine côte à côte, les diffs, les stashs, le rebase avec résolution de conflits.
• Pull requests : connexion à GitHub et Azure DevOps par code d’appareil, fils de révision, modification de ses propres commentaires, fermeture et réouverture, avec « Improve » pour peaufiner une réponse.
• Tickets : Jira, Trello et Asana, planifiés dans les versions, et une branche lancée depuis n’importe quel ticket.
• Statistiques : versions livrées, délai de livraison, fusions et combien de messages de commit l’IA a écrits.

Comment c’est fait

• Trouver le parent de chaque branche. L’arbre ne marche que si chaque branche se range sous la bonne version, alors le moteur le déduit dans l’ordre : le parent déclaré (la base d’une version, ou la branche à laquelle on l’a rattachée), puis un commit de fusion qui indique où elle est allée, puis une pull request GitHub ou Azure DevOps qui l’a intégrée (ou un squash qui la contient), et sinon la cible la plus proche par l’historique : le moins de commits à elle, puis le moins de commits manquants. Une branche dont la clé de ticket apparaît dans un squash plus récent reçoit l’étiquette « probablement fusionnée », et n’est jamais supprimée automatiquement.
• Une seule surface RPC. Tous les clients passent par la même table de méthodes : invoke de Tauri sur le bureau, POST /rpc en HTTP pour le téléphone ou un navigateur, et des outils MCP pour les agents. Une méthode ajoutée là est disponible partout.
• Le téléphone gère, l’ordinateur travaille. La version mobile embarque l’interface sans le moteur et se jumelle à un ordinateur (ou à un serveur sans fenêtre) avec un jeton.
• Un pont MCP, pour qu’un agent puisse piloter Gitnetix lui-même : claude mcp add gitnetix.
• Testé sur de vrais dépôts : un test d’intégration fait tout le parcours d’une version, de sa création jusqu’à la livraison et au tag, sur un vrai dépôt Git.