En ce moment, les développeurs s’extasiaient sur un truc appelé Jujutsu , ou “jj” pour les intimes. Au début, j’ai cru à une énième tentative de réinventer la roue puis j’ai creusé, et j’ai compris pourquoi ça fait autant parler.
Vous connaissez cette frustration avec Git ? Quand vous galérez avec l’index, que vous oubliez de stash vos modifs avant de changer de branche, ou que vous priez pour ne pas foirer votre rebase ? Eh bien, Martin von Zweigbergk, ingénieur chez Google et ancien contributeur Mercurial, a décidé qu’on méritait mieux.
Du coup, il a créé Jujutsu, un système de contrôle de version qui garde tous les avantages de Git en supprimant ses complexités.
Le principe de Jujutsu tient en une phrase : votre répertoire de travail EST un commit. Poh Poh Poh !!
Fini l’index, fini le staging area, fini les acrobaties pour synchroniser vos modifications. À chaque fois que vous sauvegardez un fichier, jj crée automatiquement un nouveau commit avec un hash différent, mais conserve un “change ID” stable qui survit aux réécritures. C’est complètement fou et pourtant ça marche.
Installation de Jujutsu
Pour installer jj, vous avez plusieurs options selon votre OS. Sur macOS avec Homebrew :
brew install jj Sur Linux, utilisez le gestionnaire de paquets de votre distribution ou installez via Cargo :
# Via Cargo (nécessite Rust) cargo install --locked jj # Sur Arch Linux pacman -S jujutsu # Sur NixOS nix-env -iA nixpkgs.jujutsu Sur Windows, utilisez Winget ou Scoop :
# Via Winget winget install --id martinvonz.jj # Via Scoop scoop bucket add extras scoop install jujutsu Une fois installé, configurez votre identité (comme avec Git) :
jj config set --user user.name "Votre Nom" jj config set --user user.email "vous@example.com" Premiers pas avec Jujutsu
Pour initialiser un nouveau repo jj ou coexister avec un repo Git existant :
# Créer un nouveau repo jj jj git init myproject # Coexister avec un repo Git existant cd existing-git-repo jj git init --git-repo=. # Cloner un repo Git avec jj jj git clone https://github.com/user/repo.git Concrètement, ça change tout. Plus besoin de git add, plus de git stash avant de changer de contexte, plus de commits temporaires pour sauvegarder votre travail en cours. Jujutsu traite votre copie de travail comme n’importe quel autre commit dans l’historique, ce qui simplifie drastiquement le modèle mental.
Voici les commandes de base pour travailler avec jj :
# Voir l'état actuel (équivalent de git status + git log) jj st jj log # Créer une nouvelle branche de travail jj new -m "Début de ma nouvelle feature" # Modifier des fichiers (pas besoin de git add !) echo "Hello Jujutsu" > README.md # Les changements sont automatiquement suivis # Voir les modifications jj diff # Créer un nouveau commit basé sur le précédent jj new -m "Ajout de la documentation" # Revenir au commit précédent jj edit @- # Naviguer dans l'historique jj edit <change-id></change-id> Gestion des conflits façon Jujutsu
Le système gère aussi les conflits différemment car là où Git vous force à résoudre immédiatement, jj peut sauvegarder les conflits directement dans l’arbre de commits , sous forme de représentation logique plutôt que de marqueurs textuels. Vous pouvez donc reporter la résolution et vous en occuper quand vous avez le temps. Une fois résolu, jj propage automatiquement la solution aux commits descendants.
# Merger deux branches (les conflits sont sauvegardés si présents) jj new branch1 branch2 # Voir les conflits jj st # Les conflits sont stockés dans le commit, vous pouvez continuer à travailler jj new -m "Travail sur autre chose pendant que le conflit existe" # Revenir résoudre le conflit plus tard jj edit <conflict-commit-id> # Après résolution manuelle jj squash # Pour intégrer la résolution</conflict-commit-id> Manipulation de l’historique
L’outil brille aussi par sa puissance d’annulation. L’operation log dépasse largement les reflogs de Git en gardant une trace atomique de toutes les modifications de références simultanément. Comme ça, vous pouvez expérimenter sans crainte, sachant qu’un simple jj undo peut rattraper n’importe quelle erreur.
# Voir l'historique des opérations jj op log # Annuler la dernière opération jj undo # Revenir à un état précédent spécifique jj op restore <operation-id> # Réorganiser des commits (équivalent de rebase interactif) jj rebase -s <source> -d <destination> # Éditer un commit ancien jj edit <change-id> # Faire vos modifications jj squash # Pour intégrer dans le commit actuel # Split un commit en plusieurs jj split</change-id></destination></operation-id> Workflow quotidien avec Jujutsu
Voici un exemple de workflow typique pour une journée de développement :
# Commencer une nouvelle feature jj new main -m "feat: ajout authentification OAuth" # Travailler sur les fichiers vim auth.js vim config.js # Pas besoin de git add ! Les changements sont auto-trackés jj diff # Voir ce qui a changé # Créer un checkpoint pour continuer jj new -m "wip: OAuth provider setup" # Oh, un bug urgent à fix sur main ! # Pas besoin de stash, on switch directement jj new main -m "fix: correction crash login" # Fix le bug vim login.js # Revenir à notre feature OAuth jj edit @- # Revient au commit précédent # Finaliser la feature jj describe -m "feat: authentification OAuth complète" # Pusher vers Git jj git push Intégration avec Git
Côté compatibilité, c’est du 100% Git. Jujutsu utilise les dépôts Git comme backend de stockage, ce qui signifie que vos collègues peuvent continuer avec Git classique sans même savoir que vous utilisez jj. Et si vous changez d’avis, supprimez juste le dossier .jj et tout redevient normal.
# Synchroniser avec le remote Git jj git fetch # Pusher vos changements jj git push # Créer une branche Git depuis un change jj jj branch create ma-feature jj git push --branch ma-feature # Importer les changements depuis Git jj git import # Exporter vers Git (automatique généralement) jj git export Commandes avancées utiles
Selon les retours d’utilisateurs , même les experts Git qui maîtrisent parfaitement les rebases complexes découvrent qu’ils n’ont plus peur de manipuler l’historique. Réordonner des commits, corriger une modification ancienne, jongler avec plusieurs branches non mergées… tout devient trivial avec jj.
# Voir l'historique en mode graphique jj log --graph # Chercher dans l'historique jj log -r 'description(regex:"fix.*bug")' # Travailler avec plusieurs parents (merge commits) jj new parent1 parent2 parent3 # Abandonner des changements locaux jj abandon <change-id> # Dupliquer un commit ailleurs jj duplicate <change-id> -d <destination> # Voir les changements entre deux commits jj diff -r <from> -r <to> # Créer un alias pour une commande fréquente jj config set --user alias.l 'log --graph -r "ancestors(., 10)"' jj l # Utilise l'alias</to></from></destination></change-id></change-id> Configuration et personnalisation
Pour personnaliser jj selon vos besoins :
# Définir votre éditeur préféré jj config set --user ui.editor "code --wait" # Activer les couleurs dans le terminal jj config set --user ui.color "always" # Configurer le format de log par défaut jj config set --user ui.default-revset "@ | ancestors(@, 10)" # Voir toute la configuration jj config list --user # Éditer directement le fichier de config jj config edit --user Le projet évolue rapidement et l’équipe travaille sur plusieurs backends, y compris un natif qui pourrait dépasser Git en performance sur de gros dépôts.
Évidemment, Jujutsu reste expérimental. L’écosystème est plus petit, les intégrations IDE limitées (bien qu’il y ait déjà des extensions VSCode et Vim), et la terminologie différente demande un temps d’adaptation. Mais pour ceux qui cherchent une approche plus intuitive du contrôle de version, ça vaut franchement le détour.
Pour aller plus loin, je vous conseille de parcourir le tutoriel officiel qui couvre des cas d’usage plus avancés, ou de rejoindre le Discord de la communauté où les développeurs sont très actifs et répondent aux questions.
Bref, vous l’aurez compris, jj ne remplace pas Git dans l’immédiat . Il le sublime en gardant la compatibilité totale. C’est une approche intelligente qui permet d’adopter progressivement un workflow plus fluide sans perturber les équipes de dev.
Un grand merci à friendly_0day pour le partage !