Git Worktree : travaillez sur plusieurs branches en même temps (sans perdre la tête)

J'ai découvert git worktree en utilisant Claude Code. L'IA jonglait entre plusieurs contextes sans jamais faire de git stash, sans changer de branche, sans perdre son état. J'ai creusé pourquoi — et c'est devenu une de mes fonctionnalités Git préférées.

Le problème que ça résout

Tu bosses sur une feature. Tu es au milieu de quelque chose, des fichiers modifiés partout. Et là : un collègue te ping, il faut checker un bug en prod sur main. Ou ton CI plante sur une autre branche et tu dois investiguer.

Ta réaction habituelle, c'est probablement l'une de ces trois options :

• git stash → changer de branche → bosser → revenir → git stash pop → prier pour qu'il n'y ait pas de conflit
• Committer un WIP dégueulasse juste pour pouvoir changer de branche
• Cloner le repo une deuxième fois dans un autre dossier

Aucune de ces options n'est satisfaisante. git worktree est la quatrième option — celle que tu ne connaissais pas.

C'est quoi concrètement ?

Un worktree (arbre de travail), c'est un répertoire de travail associé à ton dépôt Git. Par défaut, tu en as un seul : le dossier racine de ton projet.

git worktree te permet d'en créer plusieurs, chacun pointant vers une branche différente, tous partagent le même .git. Pas de clone, pas de duplication d'historique. Juste plusieurs fenêtres ouvertes sur le même repo.

mon-projet/              ← worktree principal (branche: feature/mon-truc)
  .git/
  src/
  ...

mon-projet-hotfix/       ← worktree secondaire (branche: hotfix/bug-critique)
  src/
  ...                    ← pas de .git, juste un fichier .git qui pointe vers le principal

Les commandes essentielles

Créer un worktree

# Créer un worktree sur une branche existante
git worktree add ../mon-projet-hotfix hotfix/bug-critique

# Créer un worktree ET une nouvelle branche
git worktree add -b feature/nouvelle-feature ../mon-projet-feature main

Le premier argument est le chemin du nouveau dossier (généralement en dehors du projet), le second est la **branche **.

Lister les worktrees

git worktree list

Output :

/Users/gaetan/mon-projet          abc1234 [feature/mon-truc]
/Users/gaetan/mon-projet-hotfix   def5678 [hotfix/bug-critique]

Supprimer un worktree

# D'abord supprimer le dossier, puis nettoyer la référence
git worktree remove mon-projet-hotfix

# Ou forcer si des modifications non committées traînent
git worktree remove --force mon-projet-hotfix

# Nettoyer les références orphelines (si tu as supprimé le dossier manuellement)
git worktree prune

Se déplacer dans un worktree

C'est juste un dossier. Tu ouvres un terminal dedans, tu lances ton éditeur, c'est tout.

cd ../mon-projet-hotfix
code .        # VS Code sur le worktree
ng serve      # ou ton serveur de dev Angular

Cas d'usage concrets

1. Hotfix urgent sans perdre ton contexte

C'est le cas classique. Tu es en plein milieu d'une feature, tu ne touches à rien :

# Depuis ton projet principal
git worktree add -b hotfix/login-crash ../mon-projet-hotfix main

cd ../mon-projet-hotfix
# → Tu règles le bug, tu commites, tu pousses
# → Tu reviens dans ton projet principal, tout est exactement comme tu l'as laissé

git worktree remove ../mon-projet-hotfix

2. Comparer deux branches côte à côte

Tu veux voir comment une feature se comporte sur main vs sur ta branche ? Tu lances deux ng serve sur deux ports différents, dans deux worktrees différents. Pas de checkout, pas de rebuild complet.

git worktree add ../mon-projet-main main
cd ../mon-projet-main && ng serve --port 4201
# Ton projet principal tourne déjà sur :4200

3. Review de PR sans quitter ta branche

Tu dois review une PR d'un collègue. Plutôt que de stasher ou de tout lâcher :

git fetch origin
git worktree add ../review-pr-42 origin/feature/la-pr-de-kevin

cd ../review-pr-42
# → Tu lis le code, tu fais tourner les tests, tu testes l'appli

4. Ce que fait Claude Code (et pourquoi c'est malin)

Claude Code utilise les worktrees pour travailler sur plusieurs tâches en parallèle sans créer de conflits entre ses propres sessions. Chaque agent travaille dans son propre worktree, isolé des autres, mais partage le même historique Git.

C'est ce pattern qui m'a fait découvrir la fonctionnalité — et il est tout aussi utile pour nous, humains.

Points d'attention

Une branche = un seul worktree à la fois. Tu ne peux pas avoir la même branche dans deux worktrees simultanément. Git te le dira avec une erreur explicite.

Les node_modules ne sont pas partagés. Chaque worktree a les siens. Un npm install (ou pnpm install) sera nécessaire dans chaque nouveau worktree. C'est un peu lourd, mais c'est le prix de l'isolation.

Avec Nx, pense à vérifier que le cache Nx ne crée pas de conflits entre worktrees si tu partages le même .nx/cache. En pratique c'est rare, mais garde ça en tête.

Le .git est partagé, donc les hooks, la config locale, etc. s'appliquent partout. C'est généralement ce qu'on veut.

En résumé

git worktree n'est pas une fonctionnalité révolutionnaire — elle existe depuis Git 2.5 (2015). Mais c'est une de celles qu'on découvre tard et qu'on regrette de ne pas avoir connues avant.

Si tu utilises Claude Code ou n'importe quel outil d'IA agentique sur ton code, tu y es probablement déjà confronté sans le savoir. Autant comprendre pourquoi c'est là.

📚 Envie de creuser Angular ?

👉🏼 ➡️ Découvre EasyAngularKit