VisualJJ : rendre Jujutsu (jj) simple pour versionner et revenir en arrière depuis VS Code
📌 VisualJJ ajoute à VS Code une vue claire des “changes” de Jujutsu, avec des actions concrètes (décrire, éditer, squash, rebase, abandonner) pour garder un historique propre sans passer sa journée à jongler avec des branches.
Si l’usage de Git sert surtout à versionner un projet perso et à restaurer rapidement une version qui marche quand quelque chose casse, l’approche de Jujutsu colle très bien : on travaille dans une copie de travail, on décrit ce qu’on fait, on crée une nouvelle change, et on façonne l’historique au fur et à mesure, sans étape de staging obligatoire.
VisualJJ sert de tableau de bord pour ce modèle : la logique “branches optionnelles” devient tangible, et la progression est visible, même quand on crée plusieurs changements qui partent du même parent.
Dans la pratique, ça change surtout la sensation quotidienne : au lieu de préparer un commit (add, stage, commit) puis de le pousser sur une branche, on accumule des modifications dans la change en cours, on lui donne un titre précis, puis on passe à la suivante.
On garde le même objectif que dans Git (un historique qui aide à comprendre et à revenir en arrière), mais avec moins de frictions quand on itère vite.
VisualJJ cible précisément ce moment où l’on connaît Git, on expérimente jj, et on veut un repère visuel pour ne pas se perdre dans les identifiants, les parents et les mouvements d’historique.
Points clés
• 🌳 Une arborescence de changes lisible : VisualJJ affiche le dépôt comme un arbre de changements plutôt qu’une liste de branches, ce qui aide à suivre ce qui dépend de quoi et ce qui est prêt à être “ship”.
• ✍️ Décrire plutôt que “committer” : avec jj, la commande de commit ressemble plus à une finalisation de la change actuelle, et VisualJJ encourage à nommer chaque étape avec une intention (“Fix incorrect naming”, “Documentation”, etc.).
• 🧩 Squash workflow accessible : on peut développer dans la change courante puis “squash” dans le parent, pour imiter un staging mental quand on préfère finaliser la change précédente une fois la modification validée.
• 🧱 Edit workflow naturel : créer une change avant la courante (par exemple pour glisser un refactor avant la doc) devient une action simple, et les rebases automatiques de jj sont plus faciles à appréhender quand on les voit.
• 🧯 Annuler proprement : abandonner une change revient à jeter un essai sans polluer l’historique, utile quand on teste une piste et qu’on veut repartir propre.
Pour démarrer sans se compliquer la vie, l’idée est de garder un mini-projet et d’expérimenter la boucle de base.
Créer un dossier, ajouter deux fichiers, puis initialiser avec jj.
Le statut montre immédiatement que les fichiers sont déjà dans la copie de travail : pas besoin de l’équivalent de git add.
La suite la plus pédagogique consiste à ajouter une description, puis à enchaîner une nouvelle change vide, comme si chaque “étape” de travail était un ticket miniature.
Le détail qui aide vraiment à s’y retrouver est la séparation entre change id (stable) et commit id (qui bouge quand on modifie la description ou d’autres métadonnées).
Dans un usage solo, ce change id agit comme un repère durable pour retrouver une étape logique, même si le commit id change au fil des ajustements.
À côté, la commande de log est intéressante parce qu’elle met en avant des notions propres à Jujutsu comme les revsets.
Le root commit, affiché comme root(), est immuable : il sert de base, et l’outil invite à naviguer via des fonctions qui sélectionnent des ensembles de révisions.
Sans tout apprendre d’un coup, retenir que @ désigne la copie de travail permet déjà de se déplacer : on peut éditer une change antérieure, inspecter ce qu’elle contient, puis repartir.
C’est là que VisualJJ devient un accélérateur : au lieu de mémoriser des séquences de commandes, on voit la structure des changements, leurs parents, et l’état courant.
On garde quand même intérêt à taper les commandes à la main au début, mais l’interface aide à comprendre ce qui se passe quand on fait un squash ou un rebase.
Dans le flux “squash”, la logique est simple : on décrit l’intention, on implémente dans la copie de travail, puis on transfère la modification dans le parent pour que l’historique raconte l’histoire dans le bon ordre.
Dans le flux “edit”, on décompose une tâche en petites changes, parfois en en insérant une avant la courante : commentaire, refactor, doc, ajustement.
Jujutsu rebasing automatiquement les descendants, on peut restructurer sans être bloqué par les conflits au mauvais moment.
Là encore, voir l’effet dans l’arbre aide : la non-linéarité n’est plus une surprise, elle devient un outil.
Au quotidien, le bénéfice principal pour un usage “versioning + restauration” est de pouvoir expérimenter sans peur.
On peut faire une change “essai”, la décrire, la comparer, puis l’abandonner si elle ne vaut pas la peine.
Et si une modification casse quelque chose, l’historique est déjà organisé par intentions, ce qui rend le retour à une version précédente plus direct.
Sur la partie environnement, VisualJJ vise VS Code et les éditeurs compatibles, et s’ouvre aussi aux contextes modernes (WSL, SSH remotes, dev containers) où l’on veut garder la même expérience.
L’intégration GitHub est utile même en solo : créer une pull request depuis une change peut servir à sauvegarder un jalon, à déclencher une CI, ou simplement à garder un point de restauration sur un dépôt distant.
Mais l’outil reste pertinent même sans PR : l’essentiel est la clarté de l’arbre et la facilité à façonner l’historique.
Concrètement, VisualJJ est une bonne passerelle pour qui utilise Git comme assurance-vie personnelle et veut tester Jujutsu sans perdre ses repères : on garde la compatibilité Git, on gagne une manière plus fluide de travailler par changements, et on rend la restauration vers une version stable plus naturelle.
