Un correctif doit partir avant midi. Sur votre branche actuelle, trois fichiers ont changé et la nouvelle fonctionnalité est encore loin de passer les tests. Git peut ouvrir un second dossier de travail associé au même dépôt. Cette méthode est pratique quand vous souhaitez garder sous la main les modifications, les fichiers non suivis et les fenêtres du chantier principal.
Ce qui est partagé entre les deux dossiers
Avec git worktree, chaque répertoire a ses propres fichiers, son index et sa position dans l’historique. Les objets Git et les références de branche sont partagés. Un commit réalisé dans le dossier du correctif devient visible depuis l’autre dossier. Vous pouvez passer d’un terminal à l’autre et consulter la même histoire sans déplacer la branche actuellement ouverte dans votre éditeur.
Les fichiers non suivis du premier dossier ne sont pas copiés. Les dépendances installées, les variables locales et les données de test peuvent nécessiter une préparation dans le nouveau dossier. La documentation officielle de git worktree explique les commandes d’ajout et de retrait, ainsi que les références particulières à chaque répertoire. Elle permet aussi de comprendre pourquoi Git empêche normalement d’ouvrir la même branche dans deux dossiers à la fois.
Choisir le bon point de départ
Vérifiez quelle branche correspond à la version touchée. Certaines équipes intègrent les nouveautés sur main et maintiennent une branche distincte pour la version en service. Si vous partez du mauvais commit, les tests peuvent réussir contre un code que personne n’utilise encore. Demandez le numéro de version ou la référence de livraison si elle ne figure pas dans le ticket.
Dans un projet où origin/main représente bien cette base de livraison, commencez par git fetch origin. Lancez ensuite git worktree add -b correctif-session ../projet-correctif origin/main. Cette commande crée une nouvelle branche dans un dossier voisin. Adaptez les noms au projet. Si la branche existe déjà, consultez son historique avant de choisir une autre commande ou de reprendre son travail.
Ouvrez le dossier voisin dans une seconde fenêtre de l’éditeur. Vérifiez la racine et exécutez git status depuis son terminal. Cette étape peut sembler excessive pour une intervention de cinq minutes. Elle évite pourtant un incident banal : avoir la bonne branche dans l’éditeur et lancer les tests dans l’autre dossier.
Séparer aussi les essais
Deux répertoires Git n’isolent pas deux processus. Le serveur du chantier principal peut occuper le même port que celui du correctif. Deux copies de la configuration peuvent aussi viser une base de développement commune. Un test qui vide ou recharge cette base pourrait affecter le chantier ouvert à côté. Avant de lancer le correctif, identifiez le service réellement contacté, son port et le compte utilisé.
Utilisez les réglages de test prévus par l’équipe et les données factices appropriées. Notre article sur les prototypes interactifs de GitHub aborde une autre forme de séparation, entre le prototype et la version à livrer. Dans les deux cas, les dossiers et les branches doivent avoir un rôle lisible. Un nom comme projet-correctif indique ce que vous êtes venu faire, tandis qu’un nom générique comme copie2 peut survivre longtemps sans explication.
Livrer le changement puis retirer le dossier
Reproduisez le problème dans le dossier du correctif et réalisez le changement minimal qui le résout. Avant de pousser la branche, examinez git diff et git status. Vérifiez les fichiers ajoutés, notamment ceux produits par les essais. Si le projet impose un test ou une revue, suivez la procédure de livraison habituelle. Le second répertoire donne de la liberté sur l’organisation locale. Le changement passe toujours par le même dépôt et les mêmes contrôles.
Une fois le travail terminé, affichez les dossiers avec git worktree list. Depuis un autre répertoire du dépôt, git worktree remove ../projet-correctif retire celui du correctif. Git refuse généralement de retirer un dossier qui contient des modifications ou des fichiers non suivis. Prenez le temps de les identifier avant de décider de les garder ou de les effacer. La branche peut rester disponible pour la revue ou le suivi du déploiement.
Retenez le point de départ du correctif, la commande de test et le commit livré dans le ticket. Si une régression apparaît, ces trois informations rendront le diagnostic plus rapide. Notre guide sur la reprise après une panne suit cette logique de traçabilité. Votre chantier initial peut alors reprendre avec ses propres fichiers et ses outils déjà ouverts.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
