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

# Via Cargo (nécessite Rust)
cargo install --locked jj

# Sur Arch Linux
pacman -S jujutsu

# Sur NixOS
nix-env -iA nixpkgs.jujutsu

# Via Winget
winget install --id martinvonz.jj

# Via Scoop
scoop bucket add extras
scoop install jujutsu

jj config set --user user.name "Votre Nom"
jj config set --user user.email "[email protected]"

# 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

# 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>

# 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>

# 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>

# 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

# 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

# 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>

# 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

Vous savez ce qui m’a toujours ennuyé avec git blame ? C’est qu’à chaque refactoring, chaque reformatage de code, chaque déplacement de fichier, tous les noms disparaissent pour être remplacés par celui de la personne qui a fait ces modifications. Du coup, impossible de savoir qui a vraiment écrit le code original. Heureusement, un développeur nommé Sinclair Target vient de sortir un outil qui résout ce problème.

git-who (c’est son nom) fait donc exactement ce que git blame aurait dû faire depuis le début à savoir analyser qui a vraiment contribué à votre codebase, et pas juste qui a touché les lignes en dernier. Au lieu de se contenter d’une analyse ligne par ligne comme git blame, git-who analyse les patterns de contribution sur des fichiers entiers, des dossiers, voire des composants complets.

L’installation est simple comme bonjour. Si vous êtes sur Mac avec Homebrew, un petit brew install git-who et c’est réglé. Pour les autres, vous pouvez passer par Go avec go install github.com/sinclairtarget/git-who@latest ou compiler depuis les sources si vous aimez les défis. Docker est aussi supporté pour ceux qui préfèrent…

Ce qui rend git-who vraiment intéressant, c’est ses trois modes d’analyse. Le mode table (par défaut) vous donne un tableau récapitulatif des contributions par auteur, triable par nombre de commits, lignes de code, fichiers touchés ou date de modification. C’est pratique pour identifier rapidement qui sont les principaux contributeurs d’un projet. Le mode tree affiche l’arborescence du projet avec le contributeur principal annoté pour chaque fichier et dossier. Et le mode hist génère une timeline de l’activité des commits avec le top contributeur par période.

Pour vous donner une idée concrète, Sinclair Target a fait une démo sur le projet Vim pour analyser les patterns de maintenance après le décès de Bram Moolenaar. L’outil a permis d’identifier rapidement qui avait pris le relais sur différentes parties du code. C’est quelque chose qu’il aurait été impossible à voir clairement avec un git blame classique.

La différence fondamentale donc avec git blame, c’est que git-who “comprend” le contexte. Si quelqu’un déplace un fichier ou fait un reformatage massif, git blame lui attribuera toutes les lignes alors git-who, lui, va chercher plus loin dans l’historique pour identifier les véritables auteurs du code. Il respecte même les fichiers .mailmap pour consolider les identités multiples d’un même développeur et prend en compte le fichier .git-blame-ignore-revs pour ignorer certains commits de maintenance.

Pour utiliser git-who, il suffit de faire un git who à la racine de votre projet afin d’obtenir l’analyse de base. Vous pouvez filtrer par chemin avec git who Parser/ pour analyser seulement un dossier spécifique. Le tri est customisable avec des options comme -l pour trier par lignes de code ou -m pour la date de dernière modification. Et pour une vue historique entre deux versions, git who hist v3.10.9..v3.11.9 fait le job.

Bien sûr, git-who n’est pas le seul dans sa catégorie. GitLens pour VS Code reste l’extension la plus populaire, offrant une intégration visuelle directement dans l’éditeur. Git Quick Stats est aussi une autre alternative en ligne de commande qui propose des statistiques détaillées sur les repositories. Mais aucun ne va aussi loin que git-who dans l’analyse de la véritable propriété du code.

Qui maintient réellement cette partie critique du code ? Quelle équipe a le plus contribué à ce module ? Comment les contributions ont évolué au fil du temps ? Git-who vous aide à répondre à ces questions essentielles sur la gestion de votre projet, les audits de code ou simplement pour comprendre l’histoire d’un projet open source.

Bref, j’ai trouvé ça cool… Et qui sait, peut-être qu’un jour git-who sera intégré directement dans Git ?

Source