Jujutsu, dit jj, est un gestionnaire de version dans la lignée de Git.
Il est assez récent, créé par Martin von Zweigbergk, un ingénieur de Google comme projet personnel puis adopté par Google.
Sa première qualité vient du fait d'avoir plusieurs backends possibles, actuellement uniquement Git ce qui le rend entièrement compatible avec un dépôt Git. Ensuite avec Piper, le backend interne chez Google.
On peut donc interagir avec n'importe quel dépôt git avec jj ou avec git, avec des contributeurs utilisant jj ou git et donc sur Github, Codeberg etc.
Il est particulièrement simple et intuitif. En quelque jours on s'habitue aux commandes de bases équivalentes à git dont les options sont plus cohérentes (il me semble).
Tout est enregistré dès qu'on tape n'importe quelle commande jj (exactement comme si on faisait plein de petits commit, autant de petits snapshots) et on peut revenir en arrière sur tout ce qui a été enregistré. Ce qui fait qu'il est très facile et sécurisant d'essayer une nouvelle commande ou de revenir sur un fichier même sans avoir fait de commit jj undo.
La grande différence avec git réside dans le fait qu'il n'y pas de notion de staging, on bosse directement et systématiquement dans le commit en cours. Comme indiqué précédemment, toute commande jj enregistre l'état actuel des fichiers (tous les fichiers systématiquement -sauf ignorés-, sans avoir à les ajouter). Dès qu'on est content de notre commit actuel on passe au suivant jj new.
Notre commit actuel n'a pas de description au départ, on peut lui en donner une à tout moment, soit avant de commencer à programmer soit avant de passer au commit suivant, à sa guise. Personnellement je crée la description au départ jj new -m 'correction du bug trucmuche', hack hack hack. j'ajuste éventuellement la description jj describe -m 'correction partielle du bug trucmuche' et je passe au suivant jj new .... Le raccourci plus intuitif venant de git étant jj commit -m ... qui fait un describe et new en même temps.
Autre différence importante, le rebase est par défaut. Si je reviens sur mon commit précédent, jj edit @- (ou n'importe quel autre) et ajuste quelques fichiers les commits enfants suivants seront automatiquement mis à jour également. S'il y a des conflits ça n'est pas bloquant, les conflits sont indiqués sur les commits suivants et corrigés maintenant ou plus tard ou jamais. Ca parait dangereux au départ mais c'est finalement très pratique et de toutes façons on peut toujours annuler. Certains commits peuvent être considérés comme immutables (par ex en configurant les branches remotes) et évite de créer des problèmes à l'extérieur.
La notion de branche est également différente, on parle de bookmark. C'est la notion la plus perturbante au début. Un bookmark est l'équivalent d'une branche qui ne bouge pas automatiquement (un peu comme un tag). Il faut donc "bouger" un bookmark lorsqu'on veut lui faire suivre les commits concernés. Personnellement j'utilise plusieurs branches actives, une par déploiement/client, ce qui fait que c'est finalement plus intuitif. Lorsqu'un client est mis à jour je bouge sa branche (et non l'inverse).
Pour les opérations plus complexes je trouve jj beaucoup plus intuitif et sécurisé, il est très facile de réarranger des commits, de les fusionner, de les séparer etc. Ce que je faisais beaucoup plus rarement avec git même si je ne m'en plaignais pas particulièrement.
J'ai de plus en plus de mal à décrire les différences avec git tellement j'ai adopté jj entièrement (d'où mon journal -un peu en vrac tellement enthousiasmé-, avant de tout oublier). Par curiosité au départ (et non pas par soucis avec git) et par confort et facilité par la suite, en quelques jours, sans jamais revenir en arrière depuis plusieurs mois.
La période estivale est tout à fait propice à expérimenter ce genre d'outils !
Tutoriels :
- https://docs.jj-vcs.dev/v0.44.0/tutorial/ (dernière version officielle)
- https://steveklabnik.github.io/jujutsu-tutorial/ (pour les utilisateurs git)
- https://jj-for-everyone.github.io/ (pour les utilisateurs sans expérience particulière avec git)
# v0.44.0 jj git push --all
Posté par wilk (site web personnel, Mastodon) . Évalué à 8 (+6/-0). Dernière modification le 07 août 2026 à 16:54.
Pour ceux qui suivent déjà, la v0.44.0 qui vient de sortir ajoute l'option --all à jj git push qui permet de pousser les tags, ce qui n'était pas possible avant je n'ai jamais compris pourquoi mais du coup c'est bien pratique.
Pour info il y a une nouvelle version tous les mois, le projet est en constante évolution y compris avec des changements incompatibles.
# je ne suis pas d’accord
Posté par barmic 🦦 . Évalué à 10 (+10/-0).
J’ai adopté jj il y a un an environ et j’en suis très heureux, mais je ne suis pas d’accord avec " Il est particulièrement simple et intuitif ". Je recommande pas jj à tout le monde, mais à ceux qui connaissent bien git et qui ont compris qu’une branche devrait être immutable seulement si elle est effectivement partagée.
Je me permet de ressortir,
(削除) presque tel quel (削除ここまで)(finalement pas mal réécrit), une description que j’avais fait ailleurs :J'utilise jj depuis un an, et pour moi, jj n'est pas mieux, c'est juste différent. jj est un peu plus "sans état" que git. On peut globalement faire les mêmes choses avec les deux.
Avantage de jj
les ensembles
jj propose des options très sophistiquées qui facilitent certains usages. Ce qui nécessiterait un peu de scripting dans git peut souvent être implémenté directement dans jj. Je pense en particulier au fileset et changeset. Vous pouvez facilement sélectionner tous les commits qui touchent vos fichiers *.py ou qui ont un quelque chose dans leur description et faire des opérations ensemblistes dessus. Je veux voir tous les changeset qui modifient des fichier python depuis 1 mois se fait avec :
la gestion des conflits
jj ne vous bloque pas en cas de conflits, il marque les commits comme conflictuels et à vous de le corriger quand vous le souhaiter... ou d’annuler ce que vous venez de faire avec un simple
undo.pas d’état
Vous n’avez pas besoin de changer continuellement votre HEAD pour manipuler l’historique. Vous pouvez modifier une branche sans être dessus. C’est possible au moins en parti avec git mais il ne vous pousse pas à vous en servir comme le fait jj.
Avantages de git
Des idée pel-mel de jj qui change pour un utilisateur de git
HEAD.trunk() | tags() | ~mine()(tous les commits qui ne sont pas dans le trunk, un tag, ou les miens). Je peux réécrire l'historique uniquement pour les commits mutables, même localement.Si vous utilisez beaucoup
git rebase -iet que passer du temps à configurer aux petits ognons ne vous déplais pas, jj est probablement quelque chose à essayer.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: je ne suis pas d’accord
Posté par wilk (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Oui tu as raison, intuitif c'est très subjectif. Disons plutôt qu'il a très bien collé avec mes attentes.
Par exemple je suis plutôt du genre à oublier d'ajouter un fichier avec git mais j'ai très rarement des fichiers qui traînent. Donc pour moi c'est très naturel que n'importe quel nouveau fichier soit automatiquement versionné. Pareil pour la notion de bookmark qui colle mieux que les branches avec mon fonctionnement particulier.
C'est pour ça que c'est difficile à "vendre", il faut surtout essayer et voir ensuite si ça correspond à son fonctionnement.
[^] # Re: je ne suis pas d’accord
Posté par barmic 🦦 . Évalué à 7 (+5/-0).
Pour un certain nombre de choses il ne fait "que" s’inspirer de mercurial (hg c’est trop bien).
Autre choses jj a un équivalent de git absorb inclus et c’est trop bien.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: je ne suis pas d’accord
Posté par polochon . Évalué à 3 (+2/-0).
Ou sinon! Si vous utilisez beaucoup git rebase -i mais que vous avez la flemme de tester un nouvel outil, à l'époque https://github.com/jesseduffield/lazygit m'a vraiment fait lâcher les commandes manuelles pour savourer le confort d'une bonne TUI.
Depuis, après un petit temps d'adaptation je suis passé à https://magit.vc/ , qui est encore plus confortable (je trouve).
Jj à l'air bien, mais on peut aussi retirer beaucoup de friction avec une bonne interface. J'aurais aimé connaître jj plus tôt en fait.
[^] # Re: je ne suis pas d’accord
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Testez-en 2 ! :)
Je les ai jamais essayé. Je trouve, par nature, les TUI moins agréable.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: je ne suis pas d’accord
Posté par polochon . Évalué à 2 (+1/-0).
Bien renvoyé! :D
Disons que ça reste git en dessous, donc techniquement c'est plutôt des nouvelles interfaces et tu n'as pas besoin d'apprendre de nouveaux concepts. C'est beaucoup plus simple à essayer, et ça peut permettre de répondre à un besoin ou d'améliorer ton workflow suffisemment pour que passer à autre chose que git soit moins intéressant.
Je trouve que les TUI sont assez pratiques pour découvrabilité des commandes / options, et paradoxalement je maitrise mieux git maintenant avec magit que avant. Et ça permet aussi "d'alléger" des opérations (comme donner un commit à une autre branche, que jj propose nativement) qui se font en 3 appuis touche contre une ligne de commande bien lourde dans le terminal. Mais c'est vrai, ce point est très personnel.
# Enthousiasmant
Posté par ploum (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
Tout ce que je lis sur Jujustsu donne très envie car, malgré les années d’utilisation intensive, la lecture complète du bouquin et de beaucoup de doc, je reste très maladroit avec git, ça m’arrive encore de casser un répo.
JJ fait donc très envie.
J’attends juste qu’il arrive dans Debian ;-) (unstable ou à travers extrepo)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Enthousiasmant
Posté par Benoît Sibaud (site web personnel) . Évalué à 8 (+5/-0).
[^] # Re: Enthousiasmant
Posté par ploum (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Wow, il est là depuis février et je n’avais pas réalisé !
Merci pour l’info.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Enthousiasmant
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Tu peut faire beaucoup de conneries avec jj par exemple tout push est force à la place tu a des commits immuables (tu ne peut pas force push dessus, mais tu ne peut pas non plus les modifier localement).
Tu as juste un historique beaucoup plus agréable à utiliser.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Enthousiasmant
Posté par jch . Évalué à 3 (+3/-1). Dernière modification le 09 août 2026 à 11:47.
Tu n'as pas besoin d'attendre :
jjconsiste d'un seul binaire statique, qu'il suffit que tu copies dans ton/usr/local/bin(ou ailleurs dans ton PATH).# Je n'ai pas accroché
Posté par jch . Évalué à 5 (+4/-0).
J'ai essayé JJ sur un vrai projet. Je me suis torturé pendant un mois. Puis je suis revenu à Git.
Dans mon projet, il y avait deux branches : la branche master, qui était publique, et une branche privée. La branche master était immutable (elle était poussée sur un serveur public), la branche privée était régulièrement rebased au dessus de la branche publique.
Avec Git, c'était facile :
git checkout master
...
git commit -a
git push
git checkout private
git rebase master
Je n'ai jamais trouvé un workflow satisfaisant avec JJ. Comme les étiquettes ne se mettent pas à jour automatiquement, à la différence des branches de Git, il n'était jamais clair sur quel commit je devais rebaser ma branche privée. Maintenir mes deux branches me demandait un effort cognitif important. Et c'était un petit projet. Sur mes projets plus sérieux, j'ai souvent quatre ou cinq branches de travail qui se font régulièrement rebaser sur la branche stable.
Il y a sûrement quelque chose que je n'ai pas compris, mais j'ai trouvé JJ beaucoup plus difficile à utiliser que Git pour maintenir des branches de travail.
[^] # Re: Je n'ai pas accroché
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Mon commentaire n’est pas là pour te dire ce que tu dois utiliser comme outils. J’utilise juste les usecase différents des miens pour comprendre mieux jj.
l’équivalent de ça c’est
et ça marche même si tu es sur la branche tartampion, mais j’ai peut être raté quelque chose.
Ce n’est pas identique : si tu as une branche qui part de private, elle sera elle aussi.
J’ai eu un peu de mal avec le fait que jj n’utilise pas d’arguments positionnels. Il faut se rappeler -r/-b/-f/... et -d/-t/-A/-B c’est pour ce genre de choses que je ne considère pas que jj est un git plus simple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je n'ai pas accroché
Posté par jch . Évalué à 2 (+1/-0).
Je ne comprends pas comment ça marche. Je n'ai pas besoin d'avancer la branche manuellement après jj commit ?
[^] # Re: Je n'ai pas accroché
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Oui effectivement
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je n'ai pas accroché
Posté par wilk (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Sur un projet où j'utilise beaucoup de branches toujours actives j'ai eu du mal au début et j'avais laissé tomber pour ça.
J'en suis revenu quand j'ai commencé à raisonner bookmark et plus "branche qui n'avance pas". Le bookmark étant plus proche d'un tag finalement.
Depuis quelques versions il y a
jj bookmark advance (jj b a)qui permet d'avancer le bookmark et il me semble qu'il y a des discussions en cours pour faire qu'un bookmark puisse avancer tout seul, ce qui serait un peu l'équivalent. Mais au final je trouve plus explicite d'avancer soit-même son bookmark.[^] # Re: Je n'ai pas accroché
Posté par jch . Évalué à 3 (+2/-0).
Et c'est là que quelque chose m'échappe. Quand je travaille, j'ai plusieurs « branches qui avancent ». Le concept ne semble pas exister dans JJ, il faut que j'avance les tags manuellements, ce qui à première vue représente une charge cognitive supplémentaire. J'ai l'impression qu'il y a une information qui me manque, et cela alors que j'ai lu la doc attentivement.
[^] # Re: Je n'ai pas accroché
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Tu peut te créer un alias qui commit + avance les bookmark en même temps.
De mon point de vu jj a moins d’opinion que git et l’idée que les branches devraient avancer avec les commits est une opinion.
Pour moi c’est assez naturel de ne faire bouger mes bookmarks qu’à la fin d’une session de travail. Entre autre parce que même avec git je distingue mes commits locaux et les commits que je pousse. Un commit local pour moi c’est une micro modification qui peut ne pas compiler qui n’a de sens que pour moi. Ensuite je faisais un rebase interactif pour organiser correctement mes commits, mettre au propre leur message, etc
Mais personne n’est obligé d’utiliser jj, s’il s’agit de reproduire le fonctionnement de git avec jj utiliser git sera plus efficace.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je n'ai pas accroché
Posté par jch . Évalué à 3 (+2/-0).
Je ne suis pas entièrement d'accord. Git a les tags, qui n'avancent pas, et les branches, qui avancent. C'est donc l'utilisateur qui choisit.
Personne n'est obligé, mais je suis content d'avoir joué avec, car JJ corrige plusieurs des problèmes de Git. En particulier, JJ montre que la distinction entre commit, staging area et stash n'est pas utile, ce sont juste des trees qu'on manipule de manière différente. Du coup, je suis assez frustré de ne pas pouvoir l'utiliser pour les vrais projets.
[^] # Re: Je n'ai pas accroché
Posté par wilk (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Je pense que tu n'es pas loin du raisonnement bookmark :-)
Comme barnic je trouve plus naturel de ne déplacer mes bookmarks quand le travail est prêt qu'au début. Le "describe" du premier commit identifie en quelque sorte la branche sur laquelle on travaille et le bookmark valide le travail final après avoir éventuellement réarrangé les différentes étapes.
Pour ma part dans le projet où j'ai plusieurs branches actives qui sont carrément différentes versions en prod, (je n'ai aucune branche master c'est selon que l'une ou l'autre est avancée) je me sert des bookmarks pour savoir à quel niveau sont mes déploiements.
J'ai donc les bookmarks client1, client2 etc. Si je bosse sur la version du client2 je crée un commit en suivant de son bookmark, quand le travail est terminé je déplace le bookmark client2 (il devient immutable quand je push sur la forge et ça crée le déploiement en même temps). Et ensuite je rebase le client1 sur le client2 pour qu'ils soient au final au même niveau. Ce pourrait être la même chose avec des branches features.
Autrement dit le fait de déplacer un bookmark est mon signal comme quoi j'ai déployé.
Le raisonnement est l'inverse de git les commits sont créés avant le travail les bookmarks sont créés après le travail.
[^] # Re: Je n'ai pas accroché
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
C'est vrai mais les tags légers sont tout de même moins pratiques. Un bookmark suit le changeset donc il suit lors d'un rebase ce qu'un tag ne fera pas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je n'ai pas accroché
Posté par Misc (site web personnel) . Évalué à 5 (+2/-0).
Pareil, j'ai pas accroché. J'ai tenté sur un projet solo pour voir la syntaxe (donc git push sur main en direct), mais ça m'a vachement perturbé au final. Je retenterais sans doute dans 6 mois parce que je suis pas immunisé à la propagande, mais j'ai pas trop vu d'avantage dans le workflow d'un projet solo, voir c'était même plus chiant de devoir faire 2 commandes au lieu d'une pour pousser dans main. Et j'arrive déjà à faire des git rebase -i donc même si c'est plus simple avec jj, je n'en bénéficie pas trop.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.