Git Worktree : comment travailler sur 2 branches en même temps

Introduction

Avec son gestionnaire de version Git, on a tous déjà vécu cette situation. On est en train de développer une feature, des fichiers modifiés partout, des tests à moitié terminés. Puis un bug de prod tombe. On hésite entre committer un code bancal ou tout mettre de côté avec un git stash. Dans les deux cas, on prend un risque.

Il existe pourtant une commande Git pensée pour ça : git worktree. Peu de développeurs l'utilisent. Le principe est d'avoir plusieurs branches dans des dossiers séparés, sans quitter son dépôt Git.

Cet article vous montre comment maîtriser git worktree et explore les solutions alternatives pour comprendre pourquoi cette approche est la plus efficace.

1. Le problème et les fausses bonnes solutions

Le cas est classique. On est en plein travail sur une feature quand un correctif urgent tombe. Il faut intervenir vite sans tout casser.

Voici les réflexes habituels et leurs limites.

Le premier réflexe est de faire un git stash. On met tout de côté, on corrige le bug, on revient. Mais entre temps, un collègue a modifié le même fichier. Le git stash pop génère alors un conflit. On perd des minutes à démêler un problème qui n'existait pas.

Le deuxième réflexe est de faire un commit WIP. On commit tout en vrac, on change de branche, on corrige le bug, on revient. Sauf que l'historique contient maintenant un commit WIP pas très propre. Si la branche est partagée, les collègues voient du code inachevé.

On peut tenter d'améliorer ça avec un rebase interactif : on utilise git rebase -i pour squasher le commit WIP après coup. L'historique ressort propre mais le danger est réel sur une branche partagée. En effet, après avoir fait un push, rebaser réécrit l'historique et oblige à faire un git push --force. Cette technique reste donc réservée aux branches locales, pas encore envoyées sur origin ou utilisées par une seule personne.

Dans les deux cas on a résolu un problème en en créant un autre.

On pourrait aussi cloner le dépôt une deuxième fois. Deux dossiers, deux branches, zéro interférence. Soyons honnêtes, personne n'a envie de faire ça. En effet, le clone duplique tout l'historique git. Les dépendances restent aussi à réinstaller dans chaque dossier. Ce coût existe également avec un worktree, mais la vraie différence est ailleurs. Un worktree partage le même dépôt, le même historique et la même configuration. Le clone, lui, repart de zéro sur tous ces aspects.

Comparatif des approches

Voici un résumé complet des avantages et inconvénients de chaque approche :

Ce tableau le montre clairement : git worktree combine les avantages de chaque approche sans ses défauts. Isolation complète comme le clone, mais avec l'efficacité du partage du dépôt. Idéal pour les situations d'urgence ou de travail en parallèle.

2. Git worktree pas à pas

Qu'est-ce qu'un worktree ?

Un worktree est un répertoire de travail supplémentaire rattaché au même dépôt Git. Il permet de travailler sur plusieurs branches dans des dossiers séparés en même temps. Chaque dossier pointe vers une branche différente, sans aucune interférence.

Chaque worktree a ses propres fichiers sources, les dépendances ne sont donc pas partagées. Il faut relancer un npm install ou un build Maven dans chaque worktree.

Exemples d'utilisation (correctif en urgence)

• Créer un worktree pour la branche de correctif (la branche doit déjà exister) :

<pre><code>git worktree add ../fix-urgent branche-de-fix</code></pre>

‍

• Si la branche n'existe pas, on précise la branche de départ :

<pre><code>git worktree add -b branche-de-fix ../fix-urgent master</code></pre>

‍

• On se déplace ensuite dans ce dossier pour travailler :

<pre><code>cd ../fix-urgent
# modifier, tester
git add .  # le "." désigne l'ajout de tout le contenu modifié du worktree courant (pas du dépôt principal)
# On commit uniquement les fichiers de ce worktree pour pousser notre fix urgent,
# sans toucher à la branche principale
git commit -m "Fix urgent: description du correctif"
git push origin branche-de-fix</code></pre>

Le code en cours reste intact dans le dossier principal. Aucun stash, aucun commit forcé.

Nettoyer après intervention

• Une fois le correctif livré, on supprime le worktree :

<pre><code>git worktree remove ../fix-urgent</code></pre>

‍

• On peut lister les worktrees existants à tout moment :

<pre><code>git worktree list</code></pre>

Bien configurer son IDE

Chaque worktree fonctionne comme un projet indépendant. On ouvre chaque dossier séparément dans son IDE. Dans VS Code, un simple File > Open Folder suffit. Avec plusieurs worktrees sur le disque, les noms de dossiers deviennent vite la seule façon de savoir où on en est. Adopter un préfixe par type de travail monprojet-feature-login, monprojet-fix-crash, monprojet-wip-refacto permet d'identifier d'un coup d'œil quel dossier correspond à quoi.

3. Pour aller plus loin : worktree et agents IA

Les agents IA, comme Claude Code ou GitHub Copilot, modifient des fichiers comme n'importe quel développeur. Quand on lance un agent sur une tâche longue, il bloque la branche courante. Impossible alors de travailler en parallèle sur la même base.

En dédiant un worktree à chaque agent, chacun travaille dans son propre dossier. On intègre ensuite le code via un merge et une code review.

Pour la démo, on part d'un projet avec un module d'authentification. On crée un second worktree pour la feature dashboard :

<pre><code>git worktree add ../fakeproject-dashboard -b feature/dashboard master</code></pre>

On ouvre deux terminaux côte à côte, un par worktree, et on lance Claude Code dans chacun avec la commande claude. Chaque instance reconnaît son dossier : à gauche fakeproject, à droite fakeproject-dashboard.

Chaque agent reçoit une tâche indépendante. À gauche : "ajoute une fonction logout dans auth.js". À droite : "crée un fichier dashboard.js avec une fonction getStats". Les deux s'exécutent en parallèle.

Les deux agents proposent leurs modifications. À gauche, le diff de auth.js avec la fonction logout. À droite, la création de dashboard.js.

Une fois les modifications acceptées, les deux tâches sont terminées. On constate qu'il y a zéro interférence entre les deux branches.

Les deux agents auraient même pu modifier le même fichier sans problème. L'isolation est totale pendant le développement. C'est seulement au moment d'intégrer les branches qu'un conflit peut apparaître. Alors, un git rebase sur la deuxième branche suffit à le résoudre, comme dans n'importe quelle situation de merge classique.

On nettoie ensuite avec git worktree remove et on intègre chaque branche via une merge request.

Conclusion

git worktree règle un problème précis. Mais travailler en parallèle sur des branches n'est qu'une partie du sujet. La prochaine étape est de s'intéresser aux stratégies de branching, GitFlow par exemple. GitFlow structure le travail autour de branches dédiées, une branche par feature, une pour les releases, une pour les hotfixes. C'est encore une autre façon d'organiser le travail d'une équipe.