Les worktrees sont faciles à créer et tout aussi faciles à oublier. Vous en montez un pour qu'un agent travaille sur une branche en isolation, l'agent termine, vous relisez le diff, et le répertoire reste là, sans que personne ne s'en occupe. Une semaine plus tard, git worktree list dépasse l'écran, du -sh sur le dépôt affiche douze gigaoctets, et trois de ces répertoires pointent vers des branches fusionnées et supprimées depuis des jours. Personne n'a choisi de les garder. Ils se sont accumulés parce que la création tenait d'une commande et le nettoyage d'une corvée.
C'est la partie du travail d'agents en parallèle dont personne ne vous prévient. La primitive d'isolation est bien documentée ; notre guide sur les git worktrees pour les agents de codage IA détaille en profondeur la mécanique de création et de branchement. C'est le cycle de vie après le « terminé » qui fait mal, et la situation se dégrade vite quand ce qui crée les worktrees est un agent capable d'en ouvrir cinq en une minute et dépourvu du moindre réflexe de rangement. Cet article porte sur cette seconde moitié : la discipline de nettoyage, les commandes exactes, le mode de défaillance qui guette à chaque étape, et le moment où un script artisanal ne suffit plus.
Sharkly est une réponse au problème du « qui nettoie » : il exécute chaque Task dans son propre worktree et considère ce worktree comme faisant partie du cycle de vie de la Task, plutôt que comme un répertoire qu'il faut penser à gérer. Nous y viendrons. D'abord, la mécanique, car il faut comprendre la version manuelle avant de décider d'arrêter de la faire à la main.
TL;DR
Un worktree git est un second répertoire de travail lié à un même dépôt, doté de sa propre branche, de son index et de son HEAD. Les agents les accumulent parce que chaque exécution veut son isolation et qu'aucun ne range derrière lui. Le rail de nettoyage tient en quatre commandes : git worktree list pour voir ce qui existe, git worktree remove pour supprimer un worktree terminé, git worktree prune pour effacer les métadonnées obsolètes, et git worktree lock pour protéger celui que vous voulez conserver. Chacune a son mode de défaillance, qui laisse des répertoires orphelins, du travail perdu ou des branches bloquées si vous sautez une étape. La version manuelle fonctionne pour une poignée de worktrees. Au-delà, rattachez chaque worktree à un enregistrement de tâche pour que le nettoyage ait un responsable, ce que Sharkly fait automatiquement.
Pourquoi les worktrees s'accumulent plus vite avec les agents
Un worktree a un cycle de vie qu'une personne gère naturellement : on le crée, on travaille, on fusionne, on le supprime. L'étape de suppression repose sur la mémoire d'un humain. Les agents brisent cette hypothèse dans deux directions à la fois.
D'abord, le volume. Un développeur qui fait tourner quatre agents en parallèle crée quatre worktrees par heure, et non un par jour. Notre article sur l'exécution de plusieurs agents Claude Code en parallèle explique pourquoi ce chiffre grimpe si vite. Ensuite, l'absence d'instinct de nettoyage. Un agent lit la tâche, fait le travail, écrit le résultat, puis s'arrête. Il ne se dit pas « la branche est fusionnée, ce répertoire ne sert donc plus à rien ». Les répertoires survivent donc à leur propre utilité, et ce sont les survivants qui posent problème : des checkouts obsolètes sur des branches supprimées, des expérimentations inachevées abandonnées par l'agent, et des arborescences node_modules dupliquées qui dévorent le disque dans chacun d'eux.
Le coût n'a rien d'abstrait. Chaque worktree est un checkout complet, plus tout ce que l'agent y a installé. Dix worktrees sur un dépôt JavaScript de taille moyenne, c'est dix répertoires node_modules. Le disque se remplit, git status ralentit sur l'ensemble, et la personne qui lance ensuite git worktree list ne sait plus quels répertoires correspondent à du travail actif et lesquels ne sont que des débris.
Le rail de nettoyage, étape par étape
Voici tout le cycle de vie en quatre commandes. Exécutez-les dans cet ordre et les modes de défaillance restent clos.
Voyez ce qui existe. Commencez chaque passe de nettoyage ici :
git worktree list
# /repo a1b2c3d [main]
# /repo-auth-refactor 4d5e6f7 [auth-refactor]
# /repo-fix-logging 8g9h0i1 [fix-logging]
Le mode de défaillance si vous sautez cette étape : vous supprimez le mauvais répertoire. Deux agents sur des branches aux noms similaires produisent des chemins de worktree tout aussi similaires, et supprimer celui qui est actif vous coûte du travail non commité. Lisez la liste avant de toucher à quoi que ce soit.
Supprimez un worktree terminé. Une fois la branche d'un worktree fusionnée et que vous avez confirmé qu'il ne contient rien de modifié :
git worktree remove /repo-fix-logging
Le mode de défaillance : remove refuse si le worktree comporte des modifications non commitées ou des fichiers non suivis, ce qui est le comportement sûr par défaut. Le geste risqué consiste à recourir à --force pour faire disparaître l'erreur. Un --force sur un worktree « sale » supprime du travail réel produit par un agent mais jamais commité. Si remove proteste, allez d'abord regarder le répertoire ; la protestation est généralement justifiée.
Éliminez les métadonnées obsolètes. Si un répertoire de worktree a été supprimé avec rm -rf au lieu de git worktree remove, git conserve encore un enregistrement administratif de son existence. C'est l'orphelin classique :
git worktree prune
git worktree prune --dry-run # preview first
Le mode de défaillance : sauter prune laisse des entrées fantômes dans git worktree list et, pire, git peut refuser de réutiliser une branche qu'il croit encore extraite quelque part. prune nettoie cette comptabilité. Lancez --dry-run d'abord, pour voir ce qui sera supprimé avant que ça ne le soit. La documentation de git worktree précise exactement ce que prune considère comme obsolète.
Verrouillez ceux que vous voulez conserver. Un worktree sur un disque externe lent, ou un worktree abritant une expérimentation de longue durée, ne devrait pas être éliminé par un script de nettoyage agressif :
git worktree lock /repo-experiment --reason "release repro, keep until 2.0 ships"
Le mode de défaillance : sans verrou, une tâche de nettoyage nocturne qui élimine tout ce qui est « obsolète » peut supprimer un worktree que vous avez délibérément mis de côté. Le verrou accompagné d'une raison, c'est la différence entre un script de nettoyage en lequel vous avez confiance et un script que vous désactivez après qu'il a avalé quelque chose d'important.
Là où le script de nettoyage atteint ses limites
Vous pouvez automatiser ces quatre étapes. Une tâche cron qui liste les worktrees, vérifie chaque branche par rapport à l'historique des fusions et supprime celles qui sont fusionnées, cela représente une trentaine de lignes de shell. Ça fonctionne, et pour un développeur solo qui fait tourner quelques agents, c'est suffisant. Utilisez le script quand le nombre de worktrees est faible et qu'une seule personne est responsable du dépôt.
Ce sont les limites du jugement, pas du débit. Un script peut constater qu'une branche a été fusionnée. Il ne peut pas savoir qu'un worktree contient le travail non commité d'un agent que vous n'avez pas encore relu, ni qu'une branche « obsolète » est en réalité une tâche en pause que quelqu'un compte reprendre. Dès que le nettoyage exige de connaître l'intention d'un worktree, une règle qui ne voit que l'état de git finira par supprimer quelque chose qui comptait. L'autre plafond, c'est la coordination : sur une machine partagée, le script de nettoyage d'une personne ignore ce que font les agents d'une autre, et la question « est-ce que je peux supprimer ceci sans risque » ne trouve plus de réponse dans git worktree list seul. Pour en savoir plus sur ce problème de machine partagée, consultez notre sélection d'outils pour gérer des agents de codage IA en parallèle.
Ce qu'apporte un tableau de tâches
La solution consiste à donner à chaque worktree un responsable qui survit à la session shell. Rattachez chaque worktree à un enregistrement de tâche : le nettoyage cesse alors d'être la question « quels répertoires semblent obsolètes » pour devenir « quelles tâches sont terminées et relues ».
C'est la couche où se situe Sharkly. Vous avez déjà des agents de codage ; Sharkly en fait une équipe en transformant chaque exécution en Task. Quand une Task démarre, le service local sur l'ordinateur connecté prépare un worktree isolé pour elle. Quand le résultat de la Task revient pour relecture et qu'une personne l'accepte, le cycle de vie du worktree se termine avec la Task au lieu de traîner comme un répertoire dont personne ne se souvient. La question du nettoyage a une réponse, parce que le worktree n'a jamais été anonyme.
La répartition du travail reste honnête. Les agents prennent en charge les tâches, travaillent dans des worktrees isolés, lancent les tests et renvoient le diff. Les personnes donnent la direction et décident de l'étape de fusion et de publication. Sharkly ne remplace ni Claude Code, ni Codex, ni les commandes git ci-dessus ; il ajoute l'enregistrement partagé pour que l'isolation, la progression, les résultats et le nettoyage restent visibles de la demande à la publication, au lieu de se disperser entre les terminaux. Si vous faites tourner un seul agent et que le nettoyage manuel vous prend dix secondes, vous n'en avez pas encore besoin. Quand la liste des worktrees dépasse l'écran, le problème de gestion devient le vrai problème, et notre note sur le maintien de l'humain dans la boucle au fil des exécutions d'agents couvre le volet relecture.
La checklist à appliquer dès aujourd'hui
Lancez cette passe sur tout dépôt où des agents ont travaillé :
git worktree list, et lisez-la entièrement avant de supprimer quoi que ce soit.- Pour chaque worktree terminé : vérifiez que la branche est fusionnée, assurez-vous que le répertoire est propre, puis
git worktree remove(jamais--forcesur un arbre sale). git worktree prune --dry-run, relisez le résultat, puisgit worktree prunepour effacer les métadonnées orphelines.git worktree locksur tout worktree que vous conservez délibérément, avec une raison en clair.- Vérifiez le disque :
du -shsur l'ensemble des worktrees, et supprimez les installations de dépendances dupliquées dans les arborescences mortes. - Si vous faites cela plus d'une fois par jour, arrêtez de scripter le nettoyage et attribuez plutôt un propriétaire de Task à chaque worktree.
Vous pouvez garder les quatre commandes et les exécuter à la main, ou faire passer vos agents de codage existants par Sharkly pour que le worktree soit créé, suivi et retiré avec la Task à laquelle il appartient.
