Worktree est mieux adapté comme un répertoire d'exécution ponctuel

Il y a quelque temps, la pratique courante était de préparer un worktree, puis d’ouvrir Codex / Claude Code dans ce répertoire. Parce que les modèles plus anciens ont un contexte et une mémoire limités, si l’on laisse directement le main workspace créer un worktree, il est facile, après compression du contexte, de confondre le répertoire actuel avec celui du worktree créé, ce qui peut finir par causer des confusions.
Mais cette méthode a aussi un inconvénient : elle tend à transformer le worktree en un espace de travail à long terme. Le problème, c’est que le worktree est intrinsèquement lié à une branche. Avec le temps, on finit par rencontrer des complications comme changer de branche, synchroniser ou nettoyer des branches.
Beaucoup ne distinguent pas vraiment la différence entre un worktree et un clone indépendant. Son avantage n’est pas « un répertoire supplémentaire », mais le fait qu’il partage en réalité le même dépôt, avec une bibliothèque d’objets git commune, ce qui réduit le coût de duplication et évite de refaire tout le processus de clonage réseau. Cela est particulièrement pratique pour les gros dépôts. Donc, si vous souhaitez simplement créer un répertoire d’exécution parallèle temporaire, le worktree est très adapté. Ce n’est que lorsque vous avez besoin d’une bibliothèque d’objets totalement indépendante, par exemple pour la mapper dans Docker ou une sandbox virtuelle, qu’un clone local sera plus approprié.
Du moins, pour Codex / Claude Code actuels, ce problème est moins critique. Je préfère maintenant travailler directement dans le répertoire principal, en laissant le système créer des worktrees selon les besoins, puis fusionner les modifications et supprimer le worktree une fois terminé. Cela correspond mieux à la vocation initiale du worktree : un répertoire d’exécution temporaire à faible coût, plutôt qu’un espace de travail secondaire permanent.
Pour aller plus loin, une approche que j’expérimente actuellement consiste à maintenir un workspace global, où tous les projets Codex s’ouvrent dans ce répertoire, et où il gère lui-même la création de clones et de worktrees selon des règles. Cela facilite la continuité de la mémoire globale, et si une tâche nécessite de modifier plusieurs projets en même temps, il sait comment les modifier un par un, puis faire des tests d’intégration.