Trois chantiers en même temps, zéro pagaille

Ce que c'est et pourquoi ça compte

Si vous ouvrez trois sessions de Claude Code dans le même dossier et que vous donnez à chacune un chantier différent, tôt ou tard elles se marchent sur les pieds. L'une modifie un fichier pendant que l'autre travaille dessus, et à la fin vous ne savez plus quelle modification vient de qui.

Un worktree règle exactement ce problème. C'est une copie du projet dans son propre dossier, avec sa propre branche. L'historique du projet est commun, parce que c'est une fonction de git et pas une astuce de Claude, mais les fichiers sont séparés : ce que Claude modifie dans une copie ne touche pas les autres.

Chaque session de Claude travaille dans sa copie : personne ne touche au projet principal tant que vous ne l'avez pas décidé. À la fin, vous regardez ce que chacune a fait, vous gardez ce qui marche et vous jetez le reste.

Il ne faut qu'une chose : le projet doit utiliser git et avoir au moins un commit.

1. Une session, une copie

Depuis le terminal, ouvrez chaque session directement dans sa copie. Depuis le dossier du projet, lancez :

claude --worktree bug-connexion

La version courte, -w bug-connexion, fonctionne aussi. Claude Code crée le dossier .claude/worktrees/bug-connexion sur une nouvelle branche, worktree-bug-connexion, et la session travaille dedans.

Dans une session déjà ouverte

Si la session est déjà ouverte, ou si vous n'utilisez pas le terminal, écrivez avant toute chose :

Travaille dans un nouveau worktree appelé bug-connexion.

Claude crée la copie tout seul et vous dit où il travaille. Dans l'application de bureau, vous pouvez aussi choisir l'option worktree quand vous démarrez une nouvelle session.

Répétez dans d'autres fenêtres avec d'autres noms : « page-tarifs », « tests ». Un chantier par session, avec un nom clair : dans deux heures, vous devez savoir d'un coup d'œil ce qu'il y a dans chaque copie.

Une chose à faire une seule fois : ajoutez .claude/worktrees/ au fichier .gitignore, pour que les copies n'apparaissent pas comme de nouveaux fichiers dans le projet principal. Vous pouvez le demander à Claude en une ligne.

2. À savoir avant de commencer

La copie part de la branche principale en ligne, en général main, pas de ce que vous avez sur votre ordinateur sans l'avoir encore envoyé. Si vous avez des commits que vous n'avez pas encore envoyés avec un push, ils ne sont pas dans la copie : envoyez d'abord, puis ouvrez les copies. Si le projet n'est en ligne nulle part, la copie part de là où vous en êtes.

Ensuite, il y a les fichiers. Une copie ne contient que les fichiers que git connaît : elle n'emporte pas les fichiers exclus du projet, comme .env avec les clés, ni les bibliothèques installées. Si vous partez sans, l'app de la copie ne démarre pas, ou les tests échouent pour des raisons qui n'ont rien à voir avec le chantier.

Pour avoir .env dans chaque copie, créez dans le dossier principal du projet un fichier .worktreeinclude contenant une ligne :

.env

Claude Code le lit chaque fois qu'il crée une copie et y copie les fichiers listés. Il suit les mêmes règles que .gitignore et ne copie que les fichiers que git ignore, donc il ne duplique rien du code. Si vous avez d'autres fichiers de ce genre, comme .env.local, ajoutez une ligne pour chacun.

Les bibliothèques, elles, doivent être installées. Dans la copie, demandez :

Installe ce qu'il faut dans cette copie.

3. Quand c'est fini : enregistrez et vérifiez

D'abord, enregistrez. La fusion ne voit que le travail enregistré avec un commit : ce qui reste seulement dans le dossier de la copie ne passe pas. Dans la session de la copie, écrivez :

Fais un commit de tout le travail dans cette copie.

Passez ensuite à la session principale, celle qui est ouverte dans le vrai projet, et écrivez :

Montre-moi ce que change la branche worktree-bug-connexion par rapport à main, fichier par fichier, et lance les tests.

Si la liste montre un fichier qui n'a rien à voir avec le chantier, comme la page des tarifs dans un chantier sur la connexion, demandez à Claude pourquoi il l'a touché.

4. Fusionnez ce qui marche

Toujours depuis la session principale :

Fusionne la branche worktree-bug-connexion dans main. S'il y a des conflits, arrête-toi et explique-les-moi avant de décider.

Si la branche principale de votre projet ne s'appelle pas main, par exemple master, changez le nom dans le prompt. Si vous n'êtes pas sûr, demandez à Claude.

Un conflit, c'est quand deux chantiers ont modifié les mêmes lignes de façon différente et que quelqu'un doit choisir quelle version garder. Je préfère comprendre ce que Claude choisit plutôt que de le découvrir après.

Une à la fois : d'abord une, les tests, puis la suivante. Si vous fusionnez trois branches d'affilée et que quelque chose casse ensuite, vous ne savez pas laquelle des trois est en cause.

5. Jetez ce qui ne marche pas

Quand vous fermez une session qui travaille dans une copie, Claude Code regarde s'il y a du travail dedans : fichiers modifiés, nouveaux fichiers, commits. S'il y en a, il vous demande s'il faut garder la copie ou la supprimer. Si la copie est propre et que vous n'avez pas donné de nom à la session, il la supprime tout seul.

Si le travail ne vous plaît pas, supprimez-la : le projet principal reste tel quel. Mais supprimer la copie efface le dossier et sa branche, avec tout ce qu'ils contiennent. Si vous avez déjà fusionné le travail, vous ne perdez rien, parce qu'il est déjà dans la branche principale.

Si vous voulez, avant de la supprimer, demandez :

Résume-moi ce que tu avais essayé dans cette copie

Comme ça, l'idée ne se perd pas. Si vous décidez plutôt de garder la copie, Claude Code vous affiche en sortant la commande pour la reprendre plus tard.

Pour voir combien de copies traînent, demandez à Claude ou lancez git worktree list. Pour en supprimer une à la main, il y a git worktree remove, suivi du dossier de la copie.

La règle d'or

Trois chantiers différents, trois copies. Si deux chantiers touchent les mêmes fichiers, faites-les l'un après l'autre : les copies évitent les catastrophes, pas les conflits.

Le bug de connexion et la page des tarifs se font très bien en parallèle, parce qu'ils sont dans des parties différentes de l'app. Refaire le menu et changer les couleurs de toute l'app, non : ils finissent dans les mêmes fichiers et, au moment de fusionner, vous les retrouvez tous en conflit.

Les erreurs les plus courantes

• Deux chantiers qui touchent les mêmes fichiers dans deux copies : répartissez-les par zone de l'app, ou faites-les l'un après l'autre.
• Partir sans .env et sans bibliothèques : faites préparer la copie avant de confier le chantier, ou mettez les fichiers dans le .worktreeinclude.
• Fusionner sans commit : ce qui reste seulement dans le dossier ne suit pas la branche, donc faites d'abord faire le commit dans la copie.
• Tout fusionner d'un coup : fusionnez une branche, lancez les tests, puis passez à la suivante.
• Supprimer une copie sans la regarder : la supprimer efface aussi la branche, donc fusionnez d'abord ou faites-vous résumer ce qu'elle contenait.

Check-list

• Le projet utilise git et a au moins un commit
• .claude/worktrees/ est dans le .gitignore
• Une session par chantier, chacune dans sa copie avec un nom clair
• Chaque copie a son .env et ses bibliothèques avant de commencer
• Commit dans la copie, puis vérification depuis la session principale
• Une branche à la fois, avec les tests entre deux
• Les copies devenues inutiles sont supprimées

Questions fréquentes