L'astuce Git Worktree qui élimine les démarrages à froid

Les worktrees Git offrent un moyen puissant de gérer plusieurs branches simultanément. Ils partagent l'historique d'un seul dépôt, mais chaque worktree conserve un répertoire de travail distinct. Cette séparation est fantastique pour le développement parallèle, comme lorsque vous jonglez avec plusieurs fonctionnalités ou déployez plusieurs agents de codage IA.

Voici le piège : un nouveau worktree commence presque vide. Git copie votre code, mais ignore intentionnellement les fichiers et répertoires non suivis. Cela signifie que des composants cruciaux comme node_modules pour les projets JavaScript, les fichiers de configuration ..env, ou le répertoire de build target/ de Rust sont totalement absents.

Par conséquent, chaque nouveau worktree exige une installation à froid complète et un processus de build. Vous devez réinstaller les dépendances, recompiler le code et régénérer les caches. Imaginez faire tourner cinq ou dix agents de codage, chacun ayant besoin de son propre .environment.

Chaque agent effectue ensuite son propre npm install, cargo build ou autre configuration. Cela multiplie la charge : cinq agents signifient cinq installations distinctes, cinq builds à froid et cinq fois plus d'espace disque consommé. Avant même que le travail utile ne commence, vous avez dépensé un temps considérable, des cycles CPU et des gigaoctets de stockage juste pour préparer les choses.

Worktrunk, un CLI Rust open-source, propose une solution de contournement astucieuse avec sa commande wt step copy-ignored. Cet utilitaire exploite le copy-on-write (CoW), une fonctionnalité du système de fichiers, pour intégrer instantanément les fichiers ignorés sélectionnés dans un nouveau worktree, sans copie complète traditionnelle.

Le copy-on-write est une astuce ingénieuse : les fichiers partagent initialement les mêmes blocs de disque sous-jacents. Lorsque vous modifiez un fichier dans un worktree, le système de fichiers ne copie que les blocs modifiés vers un nouvel emplacement. Cela préserve l'isolation entre les worktrees tout en évitant le coût initial de la duplication de fichiers massifs. C'est comme avoir plusieurs copies qui ne prennent magiquement de la place que lorsqu'elles divergent réellement.

Cette approche accélère considérablement la configuration. La vidéo souligne des gains impressionnants : la copie d'un dossier de build Rust de 14 Go passerait d'environ deux minutes à environ 20 secondes. Mieux encore, un premier build, qui prendrait normalement environ 68 secondes sur un nouveau worktree, peut tomber à seulement trois ou quatre secondes.

Ce sont des résultats rapportés par l'auteur, démontrant le potentiel sur les systèmes de fichiers qui prennent en charge les reflinks, tels que APFS sur macOS ou btrfs et XFS sur Linux. Bien qu'il ne s'agisse pas d'un résultat garanti pour chaque configuration, ces chiffres illustrent la réduction significative du démarrage à froid que le CoW peut offrir, surtout lorsque vous travaillez avec de gros caches de build ou des répertoires node_modules.

Avant d'attendre des résultats instantanés, il est crucial de confirmer les capacités de votre système. Le copy-on-write (CoW), ou reflinks, dépend de votre système de fichiers et de votre configuration. De nombreux Mac utilisant APFS et les systèmes de fichiers Linux comme btrfs et XFS prennent en charge cette fonctionnalité, mais les configurations non prises en charge reviendront à une copie traditionnelle plus lente.

Il est crucial de noter que le CoW est distinct des liens physiques (hard links) ou des répertoires mutables partagés. Lorsque vous modifiez un fichier dans un worktree, le système de fichiers ne duplique que les blocs modifiés, garantissant que le fichier de l'autre worktree reste intact. Cela évite les changements silencieux et inattendus dans vos .environments parallèles.

Pour vraiment comprendre l'impact, vous devriez tester la commande wt step copy-ignored de Worktrunk sur votre projet et votre disque réels. Mesurez à la fois le temps écoulé et l'utilisation du disque. Des facteurs tels que les gestionnaires de paquets, les caches des outils de build et même les configurations .worktreeinclude (pour un contrôle granulaire sur ce qui est copié) peuvent influencer les résultats.

Par exemple, un dossier de build Rust de 14 Go copié normalement prend environ deux minutes et consomme 14 Go supplémentaires. Avec les reflinks, cela peut tomber à environ 20 secondes et pratiquement zéro espace disque supplémentaire. Cela réduit considérablement les temps de build à froid, passant d'environ 68 secondes à seulement 3-4 secondes. Apprenez-en plus sur l'optimisation de vos workflows Git pour les agents IA parallèles avec Worktrunk sur Worktrunk — Git worktree management for parallel AI agent workflows. N'oubliez pas que ces chiffres sont illustratifs ; vos résultats peuvent varier !

Automatisez wt step copy-ignored en l'ajoutant aux hooks de cycle de vie de Worktrunk. Cela garantit que les nouveaux worktrees héritent automatiquement des caches utiles, mais utilisez un fichier .worktreeinclude pour spécifier quels chemins ignorés copier. Par exemple, incluez target/ pour les projets Rust ou node_modules/ pour JavaScript, mais excluez les fichiers journaux temporaires.

Sélectionnez les chemins délibérément. Les fichiers ..env contiennent souvent des secrets et ne devraient généralement pas être copiés. Les caches et les artefacts générés peuvent également être obsolètes ou spécifiques à l'environnement, ce qui peut entraîner des problèmes difficiles à déboguer. Tous les fichiers ignorés ne sont pas sûrs ou bénéfiques à partager ; choisissez avec soin.

Déployez cette optimisation avec prudence. Essayez-la d'abord sur un seul worktree. Vérifiez l'isolation appropriée et la correction du build. Comparez le démarrage à froid du nouveau worktree par rapport à une configuration complètement propre pour confirmer l'accélération, qui peut être aussi spectaculaire que la réduction d'un build Rust de 68 secondes à 3–4 secondes.

Une fois validé, automatisez l'étape de copie pour le workflow d'agent de votre équipe. Cela garantit la cohérence et maximise les avantages d'un provisionnement de worktree quasi instantané, transformant les démarrages à froid en débuts chaleureux et productifs.

Que fait la commande copy-ignored de Worktrunk ?

Elle copie les fichiers gitignored d'un worktree existant vers un nouveau, en utilisant le copy-on-write là où le système de fichiers le prend en charge.

Le copy-on-write fonctionne-t-il sur tous les disques ?

Non. Cela dépend du support du système de fichiers et de la plateforme. APFS, btrfs et certaines configurations XFS prennent en charge les reflinks ; sinon, la copie peut consommer plus de temps et d'espace disque.

Les fichiers .env sont-ils sûrs à copier dans un autre worktree ?

Uniquement si les mêmes secrets et configurations y sont appropriés. Examinez ce que vous incluez et évitez de partager des identifiants avec des projets ou des agents non approuvés.

Comment utiliser la commande ?

Installez Worktrunk et exécutez wt step copy-ignored dans le cadre de la configuration de votre worktree. Consultez la documentation de Worktrunk pour les options et la configuration actuelles.