Git ou Jujutsu, quel outil de versionning choisir pour son projet ?
Published
8 min read

Aperçu sur les deux outils
- Git
Git est le système de contrôle de version distribué (DVCS) dominant depuis plus d'une décennie. Il a été conçu principalement comme un système de fichiers adressable par contenu sur lequel a été construit un VCS. Bien que techniquement brillant, il a privilégié la puissance technique sur l'utilisabilité (UX). Sa complexité, notamment le concept de zone de staging (index), les conflits qui interrompent le flux de travail et les rebases frustrants, peut être une source de frictions pour les développeurs.
- Jujutsu
Jujutsu (JJ) est une alternative open source moderne qui a été imaginée pour résoudre les problèmes fondamentaux d'expérience utilisateur de Git.
JJ a été créé par Martin von Zweigbergk, un ingénieur Google ayant travaillé sur Mercurial. Il s'agissait initialement d'un projet personnel commencé en 2019, mais il est désormais un projet à temps plein soutenu par Google.
Le nom "Jujutsu” (JJ) vient du fait que l'exécutable est appelé jj parce qu'il est facile à taper. Il est construit en Rust, un langage réputé pour sa performance et sa sécurité.
JJ est pleinement compatible avec Git. Il utilise un dépôt Git existant comme backend de stockage (en utilisant libgit2 pour interagir avec les dépôts Git). Cette compatibilité permet une adoption individuelle à faible risque sans nécessiter que l'équipe entière migre.
Forces de Git

Le succès de Git repose sur :
Adoption massive et écosystème mature : Git est la norme de l'industrie. Il bénéficie d'une documentation étendue, d'un support communautaire important et d'un écosystème d'outils et d'intégrations (IDE, CI/CD) très développé.
Modèle de données éprouvé : Le modèle de données sous-jacent de Git est considéré comme une innovation technique incroyable.
Puissance du staging area (Index) : Bien que complexe, l'index de Git est un moyen puissant pour les utilisateurs avancés de préparer des commits focalisés en sélectionnant des parties de la copie de travail (
git add -pougit commit --interactive).Scalabilité : Git est hautement optimisé pour les grands dépôts et les historiques longs.
Forces de Jujutsu

Jujutsu excelle par son UX et sa gestion des changements dynamiques :
- Simplification du Flux de Travail
La copie de travail est un commit : JJ élimine le concept de zone de staging (index). Toutes les modifications sont automatiquement enregistrées dans un commit spécial appelé le commit de travail.
Flux sans branches (Branchless Workflow) : JJ utilise par défaut des branches anonymes. Il n'est pas nécessaire de nommer chaque petit changement. Les commits sont conservés et ne sont pas soumis à la collecte des déchets (garbage collected) tant qu'ils sont visibles.
Commutation de contexte facile : L'absence de zone de staging et la représentation du travail en cours comme un commit rendent le git stash inutile. Vous pouvez passer à un autre état de travail (
jj checkoutoujj edit) sans avoir à enregistrer ou cacher vos changements.Workspaces (Espaces de travail) : JJ supporte les espaces de travail pour gérer plusieurs états de travail distincts dans le même dépôt, facilitant le travail en parallèle sur différentes tâches.
- Manipulation de l'Historique
Commits de Changement (Changes) persistants : JJ introduit une distinction conceptuelle entre le « changement » (l'unité de travail persistante, identifiée par un Change ID stable) et le « commit » (le snapshot à un instant T). Le Change ID ne change pas même si le contenu est modifié.
Rebasage automatique des descendants : Lorsque vous réécrivez un commit (par exemple, pour corriger une faute ou améliorer le message), tous ses commits descendants sont automatiquement rebasés par-dessus. Cela simplifie grandement la gestion des piles de commits (stack management).
Commandes de manipulation avancées : JJ fournit des commandes dédiées et intuitives pour structurer l'historique, comme :
jj splitpour diviser interactivement un commit (équivalent à fairegit add -ppuis plusieursgit commit, mais en plus clair),jj squashpour fusionner les changements dans le parent,jj edit <revision>pour reprendre le travail sur un commit antérieur.
- Résolution et Sécurité
Gestion des Conflits de Première Classe : Les conflits sont enregistrés dans les commits (de manière structurée, et non seulement comme des marqueurs textuels) et peuvent être committés. Les opérations de fusion ou de rebase réussissent toujours. Cela permet de différer la résolution des conflits et d'éviter les "conflits imbriqués" complexes de Git.
Journal des opérations et Annulation (undo) : Le Operation Log suit de manière atomique et complète chaque action effectuée sur le dépôt (supérieur au reflog de Git). La commande
jj undopermet d'annuler librement la dernière opération, ce qui réduit la peur de faire des erreurs.Revsets : Un langage de requête puissant pour sélectionner les commits (inspiré de Mercurial).
Faiblesses et défis de chaque outil
- Faiblesses de Git
Complexité du Staging Area : Le modèle à trois états (répertoire de travail, index, dépôt) augmente la charge cognitive et mène à des erreurs fréquentes.
Fragilité du Rebase : L'opération s'interrompt en cas de conflit, laissant l'utilisateur dans un état modal ("detached HEAD") qui requiert des connaissances internes poussées (--continue, --abort).
Gestion du travail parallèle : Nécessite l'utilisation de
git stash(qui peut générer ses propres conflits) ou degit worktreepour basculer facilement entre les tâches.
- Défis et Limitations de Jujutsu
Jujutsu est toujours en développement actif, ce qui implique des limitations :
Fonctionnalités Git manquantes : JJ ne prend pas en charge certaines fonctionnalités plus avancées de Git :
Les submodules Git.
Le support de Git LFS (Large File Storage).
Les clones partiels et superficiels (partial/shallow clones).
Le système de hooks Git avancé, car les opérations de JJ sont exécutées en mémoire avant d'affecter le système de fichiers.
L'équivalent de
git bisect(l'implémentation est compliquée par les commits conflictuels).Les commits signés GPG sont en cours d'implémentation.
Maturité de l'écosystème : L'intégration native avec les IDE et l'écosystème d'outils est moins développée que pour Git.
Courbe d'apprentissage pour les experts Git : Les utilisateurs habitués au modèle mental Git (utiliser git add, s'attendre à ce que
jj describecrée un nouveau commit au lieu de le modifier, etc.) doivent désapprendre des habitudes.Viabilité à long terme et CLA : L'outil est fortement associé à Google, et certains utilisateurs expriment des préoccupations concernant sa viabilité future si Google cesse de le soutenir. De plus, l'exigence d'un Contributor License Agreement (CLA) pour les contributions externes est un point de friction pour certains développeurs.
💡Le CLA de Google n'exige pas le transfert de droits d'auteur, vous restez propriétaire de votre travail.Performance ponctuelle : L'initialisation de dépôts Git hybrides avec de nombreuses références (refs) peut être lente, et les commandes peuvent ralentir car JJ doit vérifier les refs Git pour les changements.
Cas d’usage : quand choisir l’un plutôt que l’autre
| Cas d’usage | Choisir Git | Choisir Jujutsu |
| UX & Simplicité | Pour les flux de travail très simples (fetch/rebase/push) où la frustration est minime. | Si le modèle mental Git est source de confusion (index, detached HEAD, stash). Si la fonction jj undo est une priorité. |
| Gestion des Conflits | Si l'utilisation de git rerere ou la résolution immédiate des conflits en phase de rebase est acceptable. | Si vous voulez committer les conflits et les résoudre plus tard, permettant ainsi à rebase de toujours réussir. |
| Manipulation d'Historique | Pour les opérations simples, bien que rebase -i soit nécessaire pour les modifications plus anciennes et soit notoirement lourd. | Si vous travaillez fréquemment avec des piles de commits (stacks) et devez modifier un commit antérieur sans effort, grâce au rebasage automatique des descendants. |
| Travail en Parallèle & Context Switching | Nécessite git stash ou git worktree, ce qui ajoute des étapes et des risques de conflits. | Idéal pour le basculement fréquent entre les tâches grâce à la représentation du travail en cours comme un commit et aux workspaces. |
| Fonctionnalités Avancées Spécifiques | Si le projet dépend de Git LFS, des submodules, des hooks complexes ou d'un git bisect intégré. | JJ manque de ces fonctionnalités pour le moment. |
| Intégration d'Outils | Si une intégration native et mature est cruciale pour votre IDE ou vos outils CI/CD spécifiques. | JJ fonctionne bien avec les outils Git existants (compatibilité backend), mais l'écosystème natif JJ est en croissance (ex. : VisualJJ pour VS Code). |
Jujutsu est une tentative ambitieuse et réussie de réimaginer l'expérience utilisateur du contrôle de version. En adoptant des primitives plus cohésives notamment en traitant la copie de travail comme un commit et en permettant aux conflits d'être des objets de première classe. JJ offre une interface utilisateur plus simple et en même temps plus puissante que Git.
Pour les développeurs qui gèrent des historiques complexes, des piles de commits et changent fréquemment de contexte, Jujutsu peut offrir des gains de productivité substantiels. La fonctionnalité jj undo élimine la peur d'expérimenter et de commettre des erreurs (un problème fréquent dans Git).
Grâce à sa compatibilité Git totale, les développeurs peuvent adopter Jujutsu localement sans perturber leurs équipes, ce qui en fait un choix à faible risque pour l'expérimentation.
Git reste indispensable si votre projet s'appuie sur les quelques fonctionnalités avancées qui manquent encore à JJ (telles que les submodules ou LFS). Cependant, pour le flux de travail quotidien de la plupart des développeurs, Jujutsu propose un paradigme qui rend la gestion du code plus fluide et moins encombrante.
- #Git
- #jujutsu
- #version control
- #projects
- #Open Source
- #tools

