Git worktree avec Claude Code

Tu as une idée qui demande de toucher à quelque chose de central : la façon dont les données sont rangées, la brique qui gère les comptes, le fichier que tout le reste importe. Tu ne sais pas si ça va marcher, et tu sais que si ça ne marche pas, tu vas passer la soirée à défaire. Alors tu ne le fais pas.

Ou tu le fais, tu poses une branche pour te couvrir, et tu découvres deux heures plus tard que la branche ne t’a rien couvert du tout.

Ce qui se passe vraiment

La branche seule ne te sauve pas

Une branche est un nom, pas un endroit. Tu n’as toujours qu’un seul répertoire de travail : les fichiers sur ton disque sont exactement les mêmes une seconde avant et une seconde après le changement de branche. Git conserve tes modifications non enregistrées à travers la bascule : elles te suivent au lieu de rester derrière. Et si elles portent sur des fichiers qui diffèrent entre les deux branches, il refuse purement et simplement de basculer. Dans les deux cas, la branche n’a rien protégé, et la supprimer ne défait rien de ce qui a été écrit. Reproduit sur un dépôt d’essai pendant l’écriture de ce parcours, après qu’un relecteur a trouvé le conseil inverse dans une leçon déjà écrite et relue.

La leçon 2 en tire la conséquence et donne le geste : on enregistre avant de lancer, puis on annule d’abord (git restore --staged --worktree .), on jette la branche ensuite. Les deux drapeaux ne sont pas de la coquetterie : sans eux, la commande restaure depuis l’index, donc elle ne défait pas ce qu’un git add lancé en chemin y a déjà mis — et un agent en lance. C’est le commit qui sauve.

Ce que la branche ne peut pas faire, et que le répertoire fait

Si le commit suffit à réparer, pourquoi un second répertoire ? Trois raisons, et aucune n’est le gain de temps.

Réparer, ce n’est pas empêcher. git restore --staged --worktree . défait ce qui a déjà été écrit dans les fichiers suivis, indexé ou non — et il ne défait pas les fichiers nouvellement créés, la leçon 2 te le fait vérifier à l’œil. Quand une session tourne dans un worktree, le harnais refuse les appels d’outil qui visent la copie principale, avant qu’ils partent. Rien n’est écrit, donc rien n’est à défaire.
Le refus couvre aussi les subagents, les ouvriers isolés qui travaillent à part et ne rendent qu’un résumé (leçon 3), lancés depuis cette session — y compris ceux qui n’avaient rien demandé.
Ta copie principale reste utilisable pendant l’essai. Ton serveur tourne, ton éditeur est ouvert, ta compilation est en cours : rien ne bascule sous tes pieds. Avec une branche, tu prêtes ton unique répertoire et tu attends.

Le seuil, pour ne pas monter un appareillage pour rien. Tu restes sur commit plus branche, comme en leçon 2, tant que tu regardes passer chaque étape, que le changement est petit et que tu ne quittes pas le clavier. Tu ouvres une copie séparée quand l’agent va travailler seul un long moment sans que tu lises chaque geste, ou quand tu veux continuer à te servir de ta copie principale pendant ce temps-là.

Le brouillon sur une feuille à part

Un worktree (le terme est déjà passé en leçon 6 et en leçon 8), c’est ça : un second répertoire de travail du même dépôt, sur sa propre branche, qui vit à côté de ta copie principale sans la toucher. L’image à garder est celle du brouillon sur une feuille à part. Tu écris à côté, tu essaies, et si c’est mauvais tu froisses la feuille sans avoir touché à la version au propre. Ce qu’elle ne doit pas te faire croire, et on y reviendra : ce n’est pas une sauvegarde. Un brouillon jeté est perdu.

Par défaut, la copie s’installe sous .claude/worktrees/<nom>/, à la racine de ton dépôt, sur une branche neuve appelée worktree-<nom>. Une idée, une copie. Faire tourner plusieurs sessions en même temps est un autre sujet, avec un autre arbitrage — c’est la leçon 15.

Ce qui traverse la cloison

Une leçon qui te dit « c’est isolé » et s’arrête là te ment par omission. Ce qui passe, et ce qui n’y est pas :

Ce qui traverse	Ce qui n’y est pas
Le répertoire `.git` du dépôt — c’est le même historique	Les fichiers non versionnés : `.env`, `.env.local` et leurs semblables
Les plugins installés au périmètre du projet (depuis la version 2.1.200)	Les dépendances installées — le répertoire ne contient que les fichiers suivis par git, rien d’autre
Les trois approbations permanentes de la leçon 8 (commandes Bash, domaines WebFetch, WebSearch), qui remontent jusqu’à la copie principale depuis la version 2.1.211

La colonne de droite se répare, et on verra comment. C’est la troisième ligne de la colonne de gauche qui piège, parce qu’elle survit à ce que tu crois avoir jeté.

À retenir — quand tu réponds « oui, ne plus demander » dans un worktree à une commande Bash, à un domaine WebFetch ou à une WebSearch, la règle n’est pas écrite dans le worktree. Elle est écrite dans le .claude/settings.local.json de la copie principale, elle vaut dans la copie principale et dans tous les autres worktrees, et elle survit à la suppression de celui où tu l’as accordée. Tu as jeté le brouillon ; tu as gardé ce que tu y as signé. Attention à ne pas généraliser : la même réponse sur une modification de fichier n’est écrite dans aucun fichier, elle vaut jusqu’à la fin de la session. La leçon 8 t’a donné le geste qui va avec : /permissions, et le fichier d’origine de chaque règle.

Et il y a une quatrième chose, documentée ailleurs : la mémoire automatique est rangée par dépôt git, donc tous les worktrees d’un même dépôt partagent le même dossier de mémoire (leçon 6). La page consacrée aux worktrees ne la cite pas : sa liste est close à trois éléments, et le quatrième est sur la page de la mémoire. Les deux pages ne se contredisent pas — ce n’est pas le motif de la leçon 6. C’est plus simple et tout aussi coûteux : une liste n’est pas un inventaire.

La base de départ n’est pas ton travail en cours

Voilà la condition qu’on n’énonce qu’à moitié partout ailleurs, et elle décide de ce que tu trouves en ouvrant ta copie. Par défaut, le réglage worktree.baseRef vaut "fresh" : la copie part de la branche par défaut du dépôt sur le remote (souvent main) et pas de là où tu en es. Si ton idée s’appuie sur trois commits que tu n’as pas encore poussés, ils ne sont pas dans le worktree, et rien ne te le dit. La valeur "head" branche depuis ton HEAD local et emporte ce que tu n’as pas poussé.

Ce réglage, comme les deux suivants, s’écrit dans le .claude/settings.json de la racine de ton dépôt — pas ailleurs, on verra plus bas pourquoi. Si le fichier existe déjà, on ajoute la clé worktree à côté des autres au lieu de remplacer le fichier :

{
  "worktree": {
    "baseRef": "head"
  }
}

Ce que je te prescris : si tu travailles sur une seule branche et que tu pousses rarement, écris "head" maintenant, avant ton premier essai — sinon ta première copie partira d’un main distant qui n’a plus rien à voir avec ton disque. Garde "fresh" seulement si ce que tu veux, précisément, c’est repartir de ce que le remote contient. On ne peut pas y mettre un nom de branche : pour partir d’une branche précise, il faut créer le worktree soi-même avec git. Et en mode "fresh" sans remote joignable, la copie retombe silencieusement sur ton HEAD local (version 2.1.208).

Réutiliser un nom ne repart pas de zéro non plus. Relancer avec un nom déjà employé rouvre le worktree existant. Avec la base "fresh", il n’est remis sur la branche par défaut que si trois conditions tiennent en même temps : aucune modification ni fichier non suivi, encore sur la branche créée par Claude Code, et aucun commit qui n’appartienne qu’à lui. Dans tous les autres cas, il rouvre là où tu l’avais laissé — et avant la version 2.1.208, c’était toujours le cas.

La friction que tu vas rencontrer avant tout le reste

Pendant qu’une session est isolée, quatre contrôles bloquent les appels d’outil avant qu’ils partent. Ils ne couvrent pas tous les mêmes outils, et cette nuance-là compte :

Le contrôle	Ce qu’il couvre
Toute écriture visant un chemin de la copie principale	`Edit`, `Write`, `NotebookEdit`
Tout répertoire de travail qui résout dans la copie principale, ou qu’il ne peut pas vérifier	Bash, PowerShell, Monitor
Toute redirection de git vers la copie principale — `git -C`, `--git-dir`, `GIT_DIR`, `GIT_WORK_TREE`, ou un `cd` glissé avant l’appel	Bash, Monitor
Toute commande dont la forme n’est pas vérifiable statiquement	Bash, Monitor

Une commande PowerShell ne passe donc que par le deuxième contrôle, pas par les deux derniers.

Le quatrième est celui qui va te surprendre, parce qu’il s’applique même quand la commande ne lance aucun git, et qu’il ne peut pas être désactivé. Il refuse les formes que le harnais ne sait pas tracer sans les exécuter : l’expansion par accolades (cp fichier.{txt,bak}, où le shell fabrique les chemins au dernier moment) et les heredocs à délimiteur non quoté, ces blocs de texte introduits par <<FIN sans guillemets. Ce n’est pas une impasse : le refus arrive à Claude comme une erreur d’outil qui nomme le worktree et lui dit de découper la commande en commandes simples et séparées. cp fichier.{txt,bak} devient cp fichier.txt fichier.bak, le heredoc devient <<'FIN'. C’est le prix de la cloison : le harnais préfère refuser ce qu’il ne sait pas lire plutôt que supposer que c’est sûr.

Ce qu’on fait

1. Ouvrir la copie

claude --worktree essai-cache

L’alias court est -w. Sans nom, Claude Code en génère un. Deux préalables : en interactif, il faut avoir accepté une fois le dialogue de confiance de ce répertoire (leçon 2), sans quoi la commande sort en erreur ; et il faut avoir ajouté .claude/worktrees/ à ton .gitignore, comme la documentation le recommande, sinon le contenu de tes copies apparaît en fichiers non suivis dans la copie principale et tu finiras par l’enregistrer par mégarde.

Si ta machine de production sert le dépôt lui-même, ne laisse pas la copie s’installer dedans : un second exemplaire complet de l’application atterrirait dans l’arborescence servie, et le .gitignore qu’on vient de poser le rendrait invisible à git status. Dans ce cas, crée le worktree hors du dépôt avec git, puis lance Claude dedans :

git worktree add ../projet-essai -b essai-cache
cd ../projet-essai && claude

2. Lui donner de quoi tourner

Un worktree ne contient que les fichiers suivis par git : il lui manque donc toujours les deux mêmes choses, les fichiers d’environnement et les dépendances. Le mécanisme officiel pour la première famille est un fichier .worktreeinclude à la racine du projet, en syntaxe .gitignore : ce qui y est listé est recopié dans chaque worktree. C’est le bon outil, et c’est celui que je te recommande. Je ne peux pas te dire que je m’en sers : j’ai réimplémenté la même chose à la main avant de le connaître. Un fichier n’est copié que s’il est à la fois listé et gitignoré, donc un fichier suivi n’est jamais dupliqué. Et le mécanisme ne joue pas du tout si tu passes par un hook WorktreeCreate — un hook étant un déclenchement automatique attaché à un événement (leçon 5) : là, c’est au script de copier les fichiers.

Deux précautions avant d’écrire ce fichier :

Ancre tes motifs, sinon ils ramassent les worktrees existants. En syntaxe .gitignore, un motif sans barre oblique s’applique à toute profondeur : .env désigne aussi bien .env à la racine que .claude/worktrees/essai/.env. Comme les worktrees vivent physiquement sous le dépôt principal, un motif nu peut désigner les fichiers d’environnement des copies déjà ouvertes. La documentation ne dit rien de la portée du balayage de .worktreeinclude, et je ne l’ai pas mesurée : ce que j’ai payé, c’est le même motif nu sur ma propre réimplémentation, qui empilait les .env des copies existantes dans la nouvelle. Le remède tient dans une barre oblique de tête : /.env plutôt que .env, vérifié avec git check-ignore dans les deux sens. Il te met à l’abri dans les deux cas.
Demande-toi quel .env tu copies. Si ton unique fichier d’environnement est celui de la production, ton essai « sans risque » démarre avec les identifiants de la vraie base, et la cloison ne porte pas là-dessus. Fabrique-toi un fichier d’essai qui pointe ailleurs, et liste celui-là.

Pour la seconde famille, les dépendances, le réglage worktree.symlinkDirectories lie des dossiers du dépôt principal dans chaque worktree au lieu de les copier — rien n’est lié par défaut. Son voisin worktree.sparsePaths fait l’inverse du côté du volume : il ne récupère sur disque que les dossiers listés, pour que les copies d’un gros dépôt démarrent vite. Les deux s’écrivent dans le même .claude/settings.json, sous la même clé worktree que baseRef. Et c’est avec le premier que se trouve le piège le plus cher de toute cette leçon.

Piège — dans ton .gitignore, une règle écrite node_modules/, avec la barre finale, veut dire « ignore ce dossier ». Dans le worktree, ce n’est plus un dossier, c’est un lien. La règle ne s’applique donc pas, et git le documente noir sur blanc : un motif terminé par / ne correspond ni à un fichier ordinaire ni à un lien symbolique du même nom. Résultat, un git add -A embarque le lien, qui porte un chemin absolu propre à ta machine et casse le dépôt sur tout autre poste. La règle qui couvre un lien, c’est le même nom sans la barre finale, vérifié dans les deux sens : node_modules/ n’attrape que le vrai dossier, node_modules attrape le dossier et le lien. Écris-la dans .git/info/exclude, local à ta machine, et pas dans le .gitignore du projet : le fichier partagé n’est pas faux, chez les autres ce sont bien des dossiers. C’est ton réglage personnel qui les remplace par des liens, donc c’est à lui de déclarer l’exception. Vérifié aussi depuis l’intérieur d’une copie : ce fichier vit dans le répertoire git commun, donc il vaut dans tous les worktrees.

3. Entrer, savoir où tu es, et sortir

Tu n’es pas obligé de décider au lancement. En pleine session, demander à Claude de travailler dans un worktree déclenche l’outil EnterWorktree ; depuis un worktree, il peut basculer vers un autre sous .claude/worktrees/, et celui qu’il quitte reste sur disque, intact. Dans l’autre sens, l’outil ExitWorktree le ramène hors de la copie — c’est le geste de retour, et c’est aussi celui qui rend à Claude le droit d’écrire dans la copie principale.

Le signe qui dit dans quelle copie tu tapes, quand tu as un doute : git rev-parse --show-toplevel rend la racine du répertoire courant — le chemin de ta copie principale, ou celui du worktree. Et git worktree list donne la liste complète avec la branche de chacun.

Entrer dans un chemin qui n’est pas sous .claude/worktrees/ déclenche une demande d’autorisation que rien ne supprime — ni une règle de permission EnterWorktree, ni « ne plus demander ». Le motif vaut d’être compris plutôt que subi : le déplacement emporte le répertoire de travail, le droit d’écriture et la configuration du projet, CLAUDE.md compris. Claude ne change pas seulement d’endroit, il change de règles. Quant à retrouver plus tard une session laissée dans une copie, c’est le sélecteur de sessions de la leçon 7 qui s’en charge.

4. Rapatrier ce qui était bon

Ton travail est dans une branche que tu viens d’apprendre à jeter. Voilà la séquence qui le remonte, avec l’endroit d’où chaque commande se lance. Dans le worktree, tu enregistres (normalement, c’est Claude qui le fait sur ta demande) avec git add -A && git commit -m "l'idée qui marchait". Puis dans la copie principale, tu récupères la branche, tu supprimes la copie, tu supprimes la branche :

git merge worktree-essai-cache
git worktree remove .claude/worktrees/essai-cache
git branch -d worktree-essai-cache

Séquence vérifiée de bout en bout sur un dépôt d’essai. Le merge se lance depuis la copie principale et pas depuis le worktree : une branche déjà sortie dans un worktree ne peut pas être sortie ailleurs.

On ne pousse jamais depuis le worktree. On rapatrie sur la branche principale, on rend compte, on s’arrête. Un push déclenche souvent un déploiement, et si tu travailles sur une seule branche depuis la machine qui sert, la frontière entre « j’ai fini d’essayer » et « c’est en ligne » n’existe pas. Cette leçon te la rend ; elle ne la rendra pas deux fois.

On n’utilise pas git stash pour ranger un travail en cours. La pile de stash appartient au dépôt, pas au worktree : git documente que tout ce qui commence par refs/ est partagé entre worktrees, et refs/stash n’est pas dans la courte liste des exceptions. Vérifié — un stash poussé depuis la copie apparaît dans git stash list de la copie principale, où n’importe quelle autre session peut le dépiler. Un commit temporaire fait le même travail sans surprise. Et si ça t’étonne qu’un git commit fonctionne depuis une copie : le bac à sable (leçon 8) autorise les écritures dans le .git partagé, mais pas dans ses répertoires hooks/ et config.

5. Jeter, et vérifier que c’est jeté

À la sortie d’une session interactive, Claude Code regarde ce que la suppression détruirait : fichiers modifiés, fichiers non suivis, commits neufs. Il y a trois issues :

L’état	Ce qui se passe
Worktree propre, session sans nom	suppression automatique du worktree et de sa branche
Worktree propre, session nommée	on te demande d’abord
Worktree avec du travail dedans	on te demande de garder ou de supprimer — et supprimer efface le dossier, la branche, et tout ce qu’ils contiennent

Encore faut-il savoir dans quelle ligne tu es :

une session prend un nom quand tu lui en donnes un (claude -n essai-cache au lancement, /rename essai-cache en cours de route) ou quand tu acceptes un plan ;
le nom ne s’affiche sur la barre de saisie que si tu es passé par /rename : celui posé avec -n se lit dans le titre du terminal et dans la liste /resume, et la documentation ne dit pas où s’affiche celui qu’une acceptation de plan a posé. Le test n’est donc pas visuel : si tu as nommé la session ou accepté un plan, on te demandera ; sinon, une copie propre part toute seule.

Le ménage automatique ne passera pas derrière toi. Le balayage périodique ne retire que les worktrees créés pour des subagents et des sessions d’arrière-plan, il saute ceux qui portent du travail, et il ne retire jamais un worktree créé avec --worktree. À la main, git worktree list puis git worktree remove <chemin> suffisent la plupart du temps ; --force s’il reste des modifications ou des fichiers non suivis. Si git refuse à cause du verrou, git worktree unlock d’abord — mais sache ce que tu casses : pendant qu’un agent travaille, Claude Code pose un git worktree lock sur son worktree pour qu’un nettoyage concurrent ne l’efface pas. Ce que ce verrou dit de lui-même n’est documenté nulle part, donc ne compte pas dessus pour savoir qui travaille. Ce qui l’est : il tombe quand l’agent finit, le balayage sait libérer celui d’une session dont le processus est mort, et il ne touche jamais un verrou que tu as posé toi-même.

Si tu automatises ce ménage, méfie-toi de ta propre mesure. Mon script de nettoyage vérifiait qu’aucune session ne travaillait dans un dossier avant de le supprimer. Et la mesure qu’il employait rend une liste vide quand elle échoue, ce qui se lit « aucune session ne tourne ». Le dispositif se retournait donc dans le mauvais sens : il supprimait des dossiers en cours d’usage précisément le jour où il ne savait plus rien. Fermé par un contrôle de vraisemblance — cette mesure rend toujours des dizaines de lignes sur une machine qui tourne, donc une liste vide veut dire qu’elle a échoué, pas que le dossier est libre. C’est le motif de la leçon 13, cette fois dans l’outil qui fait le ménage.

Ce que tu ne verras dans aucune liste. Deux cas documentés laissent le dossier sur le disque alors que la suppression a bien eu lieu côté Claude Code : quand git ne reconnaît plus le worktree (après un git worktree prune, par exemple), la session est supprimée et le dossier reste ; et quand un hook WorktreeCreate a créé la copie sans hook WorktreeRemove en face, personne ne la retire. Dans les deux cas, ni git ni le balayage de Claude Code ne les ramasseront. Le remède est manuel : regarder le contenu de .claude/worktrees/, et pas seulement la sortie de git worktree list.

Ce que ça ne fait pas

« On jette sans trace » est la promesse que j’étais censé te faire ici. Elle est fausse. Le dossier survit à ce qui l’a rempli dans les deux cas ci-dessus. La branche n’est supprimée toute seule que dans le cas propre avec session sans nom. Le balayage ne touchera jamais ce que tu as créé avec --worktree. Et les approbations permanentes que tu as accordées dedans sont ailleurs, dans la copie principale. Le mécanisme est bon ; c’est la promesse qui était trop belle. Un worktree isole des fichiers — il n’isole pas ce que ces fichiers déclenchent.

Ça ne te protège de rien de ce qui part vers l’extérieur. Une commande lancée depuis un worktree qui écrit dans une base, appelle un service distant ou déclenche une publication le fait pour de bon. La cloison porte sur les fichiers de ton dépôt, pas sur le monde — même limite que les points de restauration (leçon 7), et c’est pour ça que « on ne pousse pas depuis le worktree » n’est pas une coquetterie.

Cinq limites de plus, dans l’ordre où elles coûtent cher :

Ce n’est pas une sauvegarde. Supprimer un worktree qui porte du travail efface le dossier, la branche et tout ce qu’ils contiennent. Le brouillon froissé est perdu : l’analogie est exacte jusqu’au bout.
Ce que Claude a appris dedans reste après. La mémoire automatique est partagée entre tous les worktrees d’un même dépôt (leçon 6) : une régularité notée pendant un essai que tu as jeté continue de peser sur tes sessions suivantes.
Tes réglages personnels ne suivent pas la copie. Un CLAUDE.local.md gitignoré n’existe que dans le worktree où il a été créé. Pour les partager, la documentation dit d’importer un fichier depuis ton dossier personnel — et cet import externe déclenche une boîte d’approbation la première fois. Si tu refuses, les imports restent désactivés et la boîte ne réapparaît jamais.
Les réglages de worktree se lisent avant que la copie existe. sparsePaths et symlinkDirectories sont lus dans le répertoire de lancement ; ensuite, ce sont ceux du worktree qui valent — tout ce qui doit s’appliquer dans les copies vit donc dans le .claude/settings.json de la racine. Et sparsePaths prend les dossiers listés plus les fichiers de racine, mais pas les dossiers de racine : liste .claude explicitement pour retrouver tes réglages, tes rules et tes skills dans la copie. Tant qu’une copie éclaircie existe, git active en outre extensions.worktreeConfig dans le .git/config partagé du dépôt.
Une règle de permission ne désigne pas ce que tu crois. Les règles des réglages locaux s’ancrent sur le répertoire de lancement, pas sur la racine : dans une session worktree, une règle partagée comme Edit(/src/**) désigne le src/ de ce worktree.

Sur les skills, je te donne une déduction et je la nomme comme telle. La liste officielle de ce que les worktrees partagent est close à trois éléments et ne les mentionne pas. Déduction : les skills du projet vivent dans des fichiers suivis, donc chaque copie a les siens, à l’état de sa branche ; les skills personnels vivent dans ton dossier utilisateur, donc ils traversent. Aucune page ne l’écrit, et le même trou vaut pour les subagents et les hooks déclarés dans le projet. Autre chose que la documentation ne dit nulle part : ce qu’il advient d’un worktree quand tu fermes la fenêtre du terminal au lieu de sortir proprement. J’ai constaté que ça laisse des dossiers derrière ; observation, pas fait documenté.

Ce n’est pas un gain de temps. Ouvrir une copie, la remplir de ce qui lui manque, rapatrier, puis vérifier que tu as bien jeté : c’est plus long que d’écrire directement dans ta copie principale. Ce que tu achètes, c’est le droit d’essayer une idée dont tu ne réponds pas — et de la jeter sans négocier avec toi-même.

Et les versions bougent sous tes pieds. Chaque comportement daté ci-dessus porte son numéro de version à l’endroit où il est décrit. L’ensemble a été contrôlé le 20 août 2026 contre l’instantané de la documentation officielle du même jour, sur une machine en 2.1.234. C’est la date du dernier contrôle, pas une promesse de fraîcheur : claude --version et /help répondent pour ta machine, aujourd’hui.

Où c’est écrit

Le fond de cette leçon vient de la documentation officielle, où se trouve le détail des procédures que cette page se contente de nommer :

Les worktrees — la page principale : ce qu’un worktree partage, comment l’isolation est tenue, le choix de la base, la copie des fichiers gitignorés, la création manuelle, le nettoyage, et le hook WorktreeCreate avec son pendant WorktreeRemove ;
Les réglages pour la clé worktree, les permissions pour ce que « ne plus demander » enregistre selon le type d’outil, et les gros dépôts pour ce que sparsePaths récupère vraiment ;
côté git, git worktree pour le partage des refs et les verrous, gitignore pour les motifs — ce sont aussi les pages man de ta machine, et c’est là que je les ai vérifiées.

Ces liens pointent vers les pages anglaises, pour les raisons données en leçon 4 : la version française existe (remplace /en/ par /fr/), mais elle traduit une partie des mots que tu verras sur ton écran, et elle peut être en retard sur le fond.

Ce que cette leçon ajoute : l’ordre (pourquoi la branche ne suffit pas, ce que le répertoire achète qu’elle n’achète pas, le seuil entre les deux, ce qui reste après), la jonction entre deux faits que les pages officielles gardent séparés (le réglage de liens transforme tes dossiers ignorés en liens ; un motif .gitignore terminé par une barre ne couvre pas un lien), les motifs .worktreeinclude à ancrer, les gestes de rapatriement vérifiés de bout en bout, et la correction d’une promesse que tout le vocabulaire officiel encourage.

Le point de bascule

Une seule phrase te dira où tu en es : « j’ai supprimé le worktree ». Tant qu’elle te rassure, tu n’y es pas. Quand elle en appelle aussitôt une autre (qu’est-ce qui est resté ?), c’est fait.

Vérifier que c’est passé

Tu as trois commits en local que tu n'as pas encore poussés, et ton idée s'appuie dessus. Tu ouvres un worktree pour l'essayer. Faut-il un réglage pour y retrouver ton travail ?

Oui — sans lui il n’y sera pas, et rien ne te le dira. Par défaut, worktree.baseRef vaut "fresh" : la copie part de la branche par défaut du dépôt sur le remote, pas de là où tu en es. Le geste, si tu travailles sur une seule branche et que tu pousses rarement : ajouter la clé worktree au .claude/settings.json de la racine de ton dépôt, avec {"worktree": {"baseRef": "head"}}. Le réglage n’accepte pas un nom de branche ; pour partir d’une branche précise, il faut créer le worktree soi-même avec git. Le symptôme trompeur, c’est que tout a l’air normal : le répertoire existe, le dépôt est le bon, seul ton travail manque.

Pendant ton essai, une commande shell t'a demandé l'autorisation et tu as répondu « oui, ne plus demander ». L'essai était mauvais, tu as supprimé le worktree et sa branche. L'autorisation est partie avec ?

Non. Pour une commande Bash, cette réponse-là écrit une règle permanente dans le .claude/settings.local.json de la copie principale : elle vaut dans la copie principale et dans tous tes autres worktrees, et elle survit à la suppression de celui où tu l’as accordée — un domaine WebFetch et une WebSearch se rangent au même endroit. C’est le point où l’image du brouillon jeté cesse d’être exacte : le papier est à la poubelle, la signature est restée. Ne généralise pas : la même réponse sur une modification de fichier n’est écrite nulle part et meurt avec la session. Le geste : /permissions, qui t’affiche les règles actives et leur fichier d’origine (leçon 8).

Pour ne pas réinstaller les dépendances, tu as lié le dossier de dépendances de ta copie principale dans ton worktree. Ton .gitignore contient bien node_modules/. Tu enregistres tout d'un coup. Que part-il, et qu'est-ce que tu écris pour l'éviter ?

Le lien part avec, et il porte un chemin absolu propre à ta machine — le dépôt casse sur tout autre poste. Un motif terminé par une barre désigne un dossier ; dans le worktree, ce n’en est plus un, c’est un lien, et git documente que ce motif-là ne couvre ni un fichier ordinaire ni un lien symbolique. La ligne à poser est le même nom sans la barre finale — node_modules — dans .git/info/exclude, local à ta machine, et pas dans le .gitignore partagé : chez les autres ce sont bien des dossiers, et c’est ton réglage personnel qui introduit l’exception. Ce fichier vaut aussi dans les worktrees.