[{"data":1,"prerenderedAt":49},["ShallowReactive",2],{"doc:fr:worktrees":3},{"title":4,"lede":5,"html":6,"headings":7},"Un worktree par agent","Un worktree donne à chaque agent son propre dossier et sa propre branche, pour que plusieurs agents travaillent sur le même dépôt sans se gêner. Cette page explique comment l’activer, le préparer, fusionner son travail et le nettoyer.","\u003Ch2 id=\"a-quoi-sert-un-worktree\">À quoi sert un worktree\u003C\u002Fh2>\n\u003Cp>Un worktree git est un second dossier de travail du même dépôt, sur sa propre branche. Avec l’option « Un worktree par agent », chaque nouvel agent reçoit le sien : ses modifications restent à part, ni les autres agents ni ton propre dossier ne les voient tant que tu ne les as pas mergées, et le panneau des fichiers les liste séparément (voir \u003Ca href=\"\u002Fdocs\u002Fgit\u002F\">Git\u003C\u002Fa>).\u003C\u002Fp>\n\u003Cp>Sans worktree, tous les agents d’un projet travaillent dans le dossier du projet et leurs modifications se mélangent : Escouade les attribue alors à chaque agent d’après ses éditions.\u003C\u002Fp>\n\u003Cp>Les agents des tickets du \u003Ca href=\"\u002Fdocs\u002Fboard\u002F\">Kanban\u003C\u002Fa> travaillent toujours dans un worktree à eux, sur la branche de leur ticket, que l’option soit activée ou non. Ils suivent les mêmes réglages de dossier, de fichiers copiés et de commandes que les autres.\u003C\u002Fp>\n\u003Ch2 id=\"l-activer\">L’activer\u003C\u002Fh2>\n\u003Cp>L’option se règle par projet, et ne concerne que les agents créés ensuite : ceux qui existent déjà restent où ils sont. Trois endroits la proposent :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>la fenêtre « Nouveau projet », avec l’interrupteur « Un worktree git par agent » (désactivé par défaut) ;\u003C\u002Fli>\n\u003Cli>un clic droit sur l’onglet du projet, puis « Activer le worktree par agent » ou « Désactiver le worktree par agent » (l’entrée précise « nouveaux agents ») ;\u003C\u002Fli>\n\u003Cli>Réglages › Projets, groupe « Git », « Un worktree par agent ».\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Le dossier du projet doit être sur une branche qui a au moins un commit : un dépôt neuf, sans aucun commit, ne peut pas encore avoir de worktree. Quand un worktree ne peut pas être créé, l’agent travaille dans le dossier du projet et la conversation affiche « Worktree non créé, l’agent travaille dans le dossier du projet : … » avec la raison.\u003C\u002Fp>\n\u003Ch2 id=\"ou-il-va-et-comment-il-s-appelle\">Où il va et comment il s’appelle\u003C\u002Fh2>\n\u003Cp>Quatre réglages du projet décident de l’emplacement et des noms (Réglages › Projets, groupe « Git »). La liste complète des réglages est dans \u003Ca href=\"\u002Fdocs\u002Fsettings-projects\u002F\">les réglages des projets\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cdiv class=\"table\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Réglage\u003C\u002Fth>\n\u003Cth>Par défaut\u003C\u002Fth>\n\u003Cth>Ce qu’il fait\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>« Dossier des worktrees »\u003C\u002Ftd>\n\u003Ctd>\u003Ccode class=\"key\">.claude\u002Fworktrees\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Où vont les nouveaux worktrees : relatif au dossier du projet (\u003Ccode class=\"key\">..\u002Fapp-worktrees\u003C\u002Fcode>, \u003Ccode class=\"key\">.worktrees\u003C\u002Fcode>), à ton dossier personnel (\u003Ccode class=\"key\">~\u002Fworktrees\u002Fapp\u003C\u002Fcode>) ou complet. Sous le champ, « Le prochain : … » montre où irait le suivant. Ce ne peut pas être le dossier du projet lui-même, un dossier qui le contient ni un dossier dans \u003Ccode class=\"key\">.git\u003C\u002Fcode>. Les worktrees déjà créés restent où ils sont.\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>« Préfixe des branches des agents »\u003C\u002Ftd>\n\u003Ctd>\u003Ccode class=\"key\">escouade\u002F\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>La branche d’un nouvel agent s’appelle \u003Ccode class=\"key\"><préfixe><nom>\u003C\u002Fcode>. Vide, c’est son nom seul.\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>« Préfixe des branches des tickets »\u003C\u002Ftd>\n\u003Ctd>\u003Ccode class=\"key\">ticket\u002F\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>La branche d’un ticket, celle de sa pull request, s’appelle \u003Ccode class=\"key\"><préfixe><clé>\u003C\u002Fcode>. Vide, c’est sa clé seule.\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>« Fichiers copiés dans les worktrees »\u003C\u002Ftd>\n\u003Ctd>\u003Ccode class=\"key\">.env*\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Les fichiers que git ignore et qu’un nouveau worktree reprend du projet (voir \u003Ca href=\"#les-fichiers-copies\">plus bas\u003C\u002Fa>).\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Le dossier du worktree est \u003Ccode><dossier des worktrees>\u002F<nom de l’agent>\u003C\u002Fcode>, sur une branche nouvelle \u003Ccode><préfixe><nom de l’agent>\u003C\u002Fcode>. Si l’un des deux existe déjà, Escouade ajoute \u003Ccode class=\"key\">-2\u003C\u002Fcode>, \u003Ccode class=\"key\">-3\u003C\u002Fcode>… Un agent s’appelle d’abord \u003Ccode class=\"key\">agent-1\u003C\u002Fcode>, \u003Ccode class=\"key\">agent-2\u003C\u002Fcode>… ; quand Escouade le nomme d’après son premier message (par exemple \u003Ccode class=\"key\">refacto-auth\u003C\u002Fcode>), sa branche devient \u003Ccode>escouade\u002Frefacto-auth\u003C\u002Fcode> si ce nom est libre, alors que le dossier garde son premier nom. Un nom que tu donnes toi-même ne change jamais la branche. La carte de l’agent montre la branche sans son préfixe (\u003Ccode>⎇ refacto-auth\u003C\u002Fcode>), et son nom entier s’affiche au survol.\u003C\u002Fp>\n\u003Cp>Le worktree part du commit où se trouve le dossier du projet à ce moment-là. La branche de ce dossier devient la \u003Cstrong>branche de base\u003C\u002Fstrong> de l’agent : c’est elle que le merge et « Intégrer » visent.\u003C\u002Fp>\n\u003Cp>Quand le dossier des worktrees est dans le dépôt (le cas par défaut), Escouade l’ajoute au fichier \u003Ccode class=\"key\">.git\u002Finfo\u002Fexclude\u003C\u002Fcode> du dépôt : les worktrees n’apparaissent pas dans les changements du projet. Un dossier qui contient déjà des fichiers suivis par git est refusé : « Le dossier des worktrees … contient des fichiers suivis par git : choisis-en un autre dans les réglages du projet. »\u003C\u002Fp>\n\u003Ch2 id=\"les-fichiers-copies\">Les fichiers copiés\u003C\u002Fh2>\n\u003Cp>Un fichier comme \u003Ccode class=\"key\">.env\u003C\u002Fcode>, que git ignore, n’existe pas dans un worktree neuf. Juste après la création du worktree, Escouade y copie les fichiers du projet qui sont ignorés par git et qui correspondent à un motif du réglage « Fichiers copiés dans les worktrees ».\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Un motif par ligne, avec \u003Ccode class=\"key\">*\u003C\u002Fcode> et \u003Ccode class=\"key\">?\u003C\u002Fcode> dans un nom et \u003Ccode class=\"key\">**\u003C\u002Fcode> pour traverser des dossiers : \u003Ccode class=\"key\">.env*\u003C\u002Fcode> prend les fichiers de la racine, \u003Ccode class=\"key\">**\u002F.env*\u003C\u002Fcode> ceux de tous les dossiers. Par défaut, \u003Ccode class=\"key\">.env*\u003C\u002Fcode>.\u003C\u002Fli>\n\u003Cli>Seuls les fichiers ignorés par git sont copiés, donc aucun ne peut finir dans un commit. Un fichier suivi par git n’est jamais copié.\u003C\u002Fli>\n\u003Cli>Les copies apparaissent dans l’arborescence de \u003Ca href=\"\u002Fdocs\u002Feditor\u002F\">l’éditeur\u003C\u002Fa>, en grisé (« Ignoré par git »). Le commit direct ne les prend jamais.\u003C\u002Fli>\n\u003Cli>Si une copie échoue, la conversation le dit (« Fichiers non copiés dans le worktree : … ») et l’agent travaille sans ce fichier.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"preparer-le-worktree\">Préparer le worktree\u003C\u002Fh2>\n\u003Cp>Un worktree neuf n’a ni dépendances installées ni code généré. Le groupe « Worktrees » des réglages du projet liste les commandes que lance Escouade pour le préparer, dans la liste « À l’ouverture d’un worktree » : elles tournent dans l’ordre, dans le nouveau worktree, avant le premier message de l’agent, et ses messages attendent la fin.\u003C\u002Fp>\n\u003Cp>Chaque commande a un shell (le premier shell détecté par défaut), une ligne de commande (par exemple \u003Ccode>npm ci\u003C\u002Fcode>) et un « Sous-dossier » du worktree (vide, c’est sa racine). « + Ajouter une commande » en ajoute une, la croix la supprime. Pour changer l’ordre, utilise les boutons ↑ et ↓ de la commande, ou \u003Ccode class=\"key\">Alt+↑\u003C\u002Fcode> et \u003Ccode class=\"key\">Alt+↓\u003C\u002Fcode> (\u003Ccode class=\"key\">⌥↑\u003C\u002Fcode> et \u003Ccode class=\"key\">⌥↓\u003C\u002Fcode> sous macOS) depuis n’importe quel champ de la commande. Une commande vide est ignorée.\u003C\u002Fp>\n\u003Cp>Les commandes reçoivent ces variables d’environnement :\u003C\u002Fp>\n\u003Cdiv class=\"table\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Variable\u003C\u002Fth>\n\u003Cth>Valeur\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>\u003Ccode class=\"key\">ESCOUADE_PROJECT_DIR\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Le dossier du projet.\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>ESCOUADE_WORKTREE_DIR\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Le dossier du worktree.\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode class=\"key\">ESCOUADE_BRANCH\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>La branche du worktree.\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode class=\"key\">ESCOUADE_PORT_BASE\u003C\u002Fcode>, \u003Ccode class=\"key\">ESCOUADE_PORT_END\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Les ports réservés au worktree d’un ticket, quand il en a (voir \u003Ca href=\"\u002Fdocs\u002Ftesting\u002F\">les tests\u003C\u002Fa>).\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Le proxy du réglage « Proxy HTTP(S) » est transmis aux commandes quand « Appliquer aussi le proxy aux terminaux intégrés » est activé (voir \u003Ca href=\"\u002Fdocs\u002Fsettings-network\u002F\">les réglages du réseau\u003C\u002Fa>). Une commande qui dépasse 20 minutes est arrêtée.\u003C\u002Fp>\n\u003Ch3 id=\"suivre-la-preparation\">Suivre la préparation\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>La carte de l’agent dit « Préparation… » ; son info-bulle donne la commande en cours.\u003C\u002Fli>\n\u003Cli>La conversation affiche « Préparation du worktree · npm ci — tes messages partiront une fois terminée. » Le bouton « Voir la sortie » déplie les dernières lignes de ce que la commande écrit, en direct. La sortie suit les nouvelles lignes tant que tu es en bas, et reste en place si tu remontes.\u003C\u002Fli>\n\u003Cli>Un message que tu envoies pendant la préparation attend : il part une fois la préparation finie.\u003C\u002Fli>\n\u003Cli>À la fin, la conversation note « Worktree préparé (3 commandes, 12 s). »\u003C\u002Fli>\n\u003Cli>La sortie complète de la dernière préparation, commande après commande, est écrite dans \u003Ccode class=\"key\">~\u002F.escouade\u002Flogs\u002F\u003C\u002Fcode>, un fichier par agent nommé \u003Ccode><identifiant de l’agent>-setup.log\u003C\u002Fcode>. Il est remplacé à chaque préparation et supprimé avec l’agent.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Archiver ou supprimer l’agent pendant sa préparation l’arrête.\u003C\u002Fp>\n\u003Ch3 id=\"quand-une-commande-echoue\">Quand une commande échoue\u003C\u002Fh3>\n\u003Cp>La première commande qui échoue arrête la préparation : les suivantes ne tournent pas. La conversation affiche un avertissement, par exemple « La préparation du worktree a échoué sur \u003Ccode>npm ci\u003C\u002Fcode> (code 1). », suivi des 30 dernières lignes de la sortie et du chemin de la sortie complète (« Sortie complète : … »). L’échec peut aussi venir d’un sous-dossier qui n’existe pas dans le worktree, d’une commande qui ne démarre pas ou d’une commande arrêtée après 20 minutes.\u003C\u002Fp>\n\u003Cp>L’agent est prévenu dans son premier message, avec la commande qui a échoué et ses dernières lignes, et il démarre quand même : il peut en tenir compte.\u003C\u002Fp>\n\u003Ch3 id=\"remplir-automatiquement\">Remplir automatiquement\u003C\u002Fh3>\n\u003Cp>« ✦ Remplir automatiquement », en haut du groupe « Worktrees », demande à Claude de lire le projet (manifestes, lockfiles, README…) et de proposer les commandes. Il ne modifie rien : il n’a que des outils de lecture, et il dispose de 4 minutes au plus. Sa proposition s’affiche à part, sous « Commandes de worktree proposées », avec chaque commande en entier, son shell et son dossier :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>« Remplacer les commandes » remplace les deux listes du brouillon (préparation et démontage). Rien n’est gardé tant que tu n’as pas cliqué « Enregistrer » dans la fenêtre des réglages ;\u003C\u002Fli>\n\u003Cli>« Ignorer » abandonne la proposition.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Claude propose huit commandes au plus par liste. Une commande sur plusieurs lignes, avec des caractères invisibles, avec une suite de 24 espaces ou plus, ou de plus de 300 caractères est écartée, et le message qui suit la lecture le dit (« 2 commandes proposées, 1 écartée (caractères invisibles ou trop longue) : relis-les avant d’enregistrer. »).\u003C\u002Fp>\n\u003Cdiv class=\"callout warning\">\u003Cp class=\"callout-title\">Attention\u003C\u002Fp>\u003Cp>Une fois enregistrées, ces commandes tournent seules dans chaque nouveau worktree. Lis chacune en entier avant d’enregistrer.\u003C\u002Fp>\n\u003C\u002Fdiv>\n\u003Ch2 id=\"demonter-le-worktree\">Démonter le worktree\u003C\u002Fh2>\n\u003Cp>La liste « Avant sa suppression » contient ce qu’il faut défaire hors du worktree avant de le supprimer : une base de données ou des conteneurs que la préparation a créés pour lui. Le plus souvent, elle est vide. Elle s’édite comme celle de la préparation, et se remplit aussi avec « ✦ Remplir automatiquement ».\u003C\u002Fp>\n\u003Cp>Ces commandes tournent quand un agent est supprimé avec son worktree, et quand le Kanban nettoie le worktree d’un ticket. Chacune tourne même si la précédente a échoué, avec 5 minutes au plus, et leur sortie n’est pas affichée. Si le projet utilise isola (un fichier \u003Ccode class=\"key\">.isola.toml\u003C\u002Fcode>), \u003Ccode>isola destroy\u003C\u002Fcode> passe ensuite. Un problème est signalé une fois l’agent supprimé : « Agent supprimé, mais le démontage du worktree a échoué sur … ».\u003C\u002Fp>\n\u003Ch2 id=\"travailler-sur-une-branche-qui-existe-deja\">Travailler sur une branche qui existe déjà\u003C\u002Fh2>\n\u003Cp>Un agent peut aussi travailler dans un worktree sur une branche qui existe déjà, au lieu d’en créer une nouvelle :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>« Nouvel agent sur une branche… » dans le menu du bouton ▾, à droite de « Nouvel agent », ouvre le sélecteur de branches (« Choisir une branche ») ;\u003C\u002Fli>\n\u003Cli>dans le sélecteur de branches de la barre d’état, un clic droit sur une branche propose « Lancer un agent sur cette branche » ;\u003C\u002Fli>\n\u003Cli>dans le formulaire d’un ticket, le champ « Branche » propose « Reprendre une branche existante… ».\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Une branche distante est reprise par la branche locale qui la suit, créée si elle n’existe pas. Le dossier du projet n’est pas touché. Trois branches sont refusées, avec la raison : celle du dossier du projet, la branche cible du Kanban (les tickets y sont mergés) et celle qu’un autre worktree occupe déjà.\u003C\u002Fp>\n\u003Cp>Cette branche est celle de l’agent, mais elle n’est jamais créée ni supprimée par Escouade : en supprimant l’agent, la case propose « Supprimer aussi le worktree (la branche … est conservée) ». Sa branche de base est la branche cible du Kanban si elle existe, sinon la branche du dossier du projet. Pour un ticket, l’infobulle de l’entrée dit « Escouade ne supprime jamais cette branche, même une fois le ticket validé. » Les branches sont détaillées dans \u003Ca href=\"\u002Fdocs\u002Fbranches\u002F\">la page des branches\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2 id=\"fusionner-dans-la-branche-de-base\">Fusionner dans la branche de base\u003C\u002Fh2>\n\u003Cp>Quand le travail d’un agent te convient, tu le fusionnes dans sa branche de base depuis le panneau des fichiers :\u003C\u002Fp>\n\u003Col>\n\u003Cli>L’agent doit avoir commité son travail (voir \u003Ca href=\"\u002Fdocs\u002Fgit\u002F\">Git\u003C\u002Fa>). Le merge ne prend que des commits.\u003C\u002Fli>\n\u003Cli>Dans le panneau, onglet « Non commités », bouton « Cet agent », clique « Merger escouade\u002Frefacto-auth → main… ».\u003C\u002Fli>\n\u003Cli>La fenêtre demande « Merger escouade\u002Frefacto-auth dans main ? » et précise que les commits de l’agent sont intégrés dans la branche « main » du projet. La case « Squash (un seul commit) » est décochée par défaut. Clique « Merger ».\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Le merge se fait dans le dossier du projet.\u003C\u002Fp>\n\u003Cdiv class=\"table\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Choix\u003C\u002Fth>\n\u003Cth>Résultat\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Sans « Squash »\u003C\u002Ftd>\n\u003Ctd>Un commit de merge (\u003Ccode>Merge branch 'escouade\u002Frefacto-auth'\u003C\u002Fcode>) qui garde tous les commits de l’agent.\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Avec « Squash (un seul commit) »\u003C\u002Ftd>\n\u003Ctd>Un seul commit, nommé d’après l’agent, qui liste les sujets des commits regroupés.\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Escouade refuse le merge, avec un message, dans ces cas :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>l’agent a des fichiers non commités (« L’agent a 2 fichiers non commités : demande-lui de commiter avant de merger. ») ;\u003C\u002Fli>\n\u003Cli>le dossier du projet a des modifications non commitées sur des fichiers suivis : commite-les ou mets-les de côté ;\u003C\u002Fli>\n\u003Cli>la branche de l’agent n’a aucun nouveau commit (« Rien à merger ») ;\u003C\u002Fli>\n\u003Cli>la branche de base n’existe plus.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Si le dossier du projet n’est pas sur la branche de base, une question s’affiche : « Basculer sur « main » ? » Elle dit sur quelle branche est le projet. « Basculer et merger » bascule le dossier sur la base, puis merge.\u003C\u002Fp>\n\u003Cp>Un merge qui a des conflits est annulé : le dossier du projet reste comme avant et un message d’erreur s’affiche. Dans ce cas, fais d’abord entrer la base dans la branche de l’agent avec « Intégrer main », qui confie les conflits à l’agent (voir \u003Ca href=\"\u002Fdocs\u002Fbranches\u002F\">les branches\u003C\u002Fa>), puis recommence.\u003C\u002Fp>\n\u003Cp>Le merge ne supprime ni le worktree ni la branche de l’agent. Pour les ranger, supprime l’agent avec son worktree (voir ci-dessous) ; pour nettoyer d’un coup les branches déjà mergées, utilise « Branches mergées » dans \u003Ca href=\"\u002Fdocs\u002Fbranches\u002F\">le sélecteur de branches\u003C\u002Fa>. Pour les tickets du Kanban, la validation se charge du commit, du merge ou de la pull request selon les réglages (voir \u003Ca href=\"\u002Fdocs\u002Fsettings-board\u002F\">les réglages du Kanban\u003C\u002Fa>).\u003C\u002Fp>\n\u003Ch2 id=\"archiver-restaurer-supprimer\">Archiver, restaurer, supprimer\u003C\u002Fh2>\n\u003Cp>Les actions sont dans le menu d’un clic droit sur la carte de l’agent.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>« Archiver » arrête l’agent et garde sa conversation. Son worktree et sa branche restent sur le disque. La confirmation n’apparaît que pour un agent dont le ticket est en cours ou à tester.\u003C\u002Fli>\n\u003Cli>« Restaurer » ramène un agent archivé. Si son dossier de worktree a disparu entre-temps, par exemple après une pull request ou un push, Escouade le recrée à partir de sa branche, recopie les fichiers du projet et relance la préparation. Si un autre worktree a pris son dossier, le sien est recréé à côté (\u003Ccode class=\"key\">-2\u003C\u002Fcode>) et la conversation l’indique. Si la branche n’existe plus (mergée puis supprimée), l’agent reste tel quel.\u003C\u002Fli>\n\u003Cli>« Supprimer… » demande confirmation. La case « Supprimer aussi le worktree et la branche escouade\u002Frefacto-auth » est cochée par défaut. Cochée, Escouade arrête l’agent, lance les commandes de démontage, supprime le dossier du worktree puis la branche. Décochée, l’agent disparaît d’Escouade et le worktree et la branche restent sur le disque. Si des fichiers de ce worktree sont ouverts et non enregistrés dans l’éditeur, la fenêtre prévient qu’ils seront perdus.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cdiv class=\"callout warning\">\u003Cp class=\"callout-title\">Attention\u003C\u002Fp>\u003Cp>La branche de l’agent est supprimée même si elle n’a pas été mergée : ses commits n’existent alors plus nulle part. Merge-la d’abord si tu veux garder son travail.\u003C\u002Fp>\n\u003C\u002Fdiv>\n\u003Cp>Si le nettoyage rencontre un problème (un processus qui tient encore le dossier, un démontage qui échoue), l’agent est supprimé quand même et un message le signale après coup. Fermer un projet ne touche pas à ses worktrees sur le disque.\u003C\u002Fp>\n\u003Ch2 id=\"dupliquer-un-agent\">Dupliquer un agent\u003C\u002Fh2>\n\u003Cp>« Dupliquer la conversation » (menu de l’agent) copie un agent qui a un worktree dans un worktree à lui, créé à partir du commit où se trouve l’original, sur une nouvelle branche dont le nom reprend celui de la copie. Les modifications non commitées de l’original n’y sont pas, et la conversation le dit. Voir \u003Ca href=\"\u002Fdocs\u002Fmanaging-agents\u002F\">les agents\u003C\u002Fa>.\u003C\u002Fp>\n",[8,12,15,18,21,24,28,31,34,37,40,43,46],{"id":9,"text":10,"depth":11},"a-quoi-sert-un-worktree","À quoi sert un worktree",2,{"id":13,"text":14,"depth":11},"l-activer","L’activer",{"id":16,"text":17,"depth":11},"ou-il-va-et-comment-il-s-appelle","Où il va et comment il s’appelle",{"id":19,"text":20,"depth":11},"les-fichiers-copies","Les fichiers copiés",{"id":22,"text":23,"depth":11},"preparer-le-worktree","Préparer le worktree",{"id":25,"text":26,"depth":27},"suivre-la-preparation","Suivre la préparation",3,{"id":29,"text":30,"depth":27},"quand-une-commande-echoue","Quand une commande échoue",{"id":32,"text":33,"depth":27},"remplir-automatiquement","Remplir automatiquement",{"id":35,"text":36,"depth":11},"demonter-le-worktree","Démonter le worktree",{"id":38,"text":39,"depth":11},"travailler-sur-une-branche-qui-existe-deja","Travailler sur une branche qui existe déjà",{"id":41,"text":42,"depth":11},"fusionner-dans-la-branche-de-base","Fusionner dans la branche de base",{"id":44,"text":45,"depth":11},"archiver-restaurer-supprimer","Archiver, restaurer, supprimer",{"id":47,"text":48,"depth":11},"dupliquer-un-agent","Dupliquer un agent",1791926754941]