--- service: "Publicasta" schema_version: "1.0" article_id: 881 title: "GitHub Desktop 3.6.7 corrige les cas limites qui rendent les worktrees risqués" language: "fr" default_language: "en" canonical_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=fr" json_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=fr" api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=fr" channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar" channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-10-14T13:38:44+00:00" updated_at: "2026-10-14T13:38:44+00:00" translations: - language: "ar" html_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=ar" markdown_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=ar" json_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=ar" - language: "de" html_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=de" markdown_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=de" json_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=de" - language: "en" html_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=en" markdown_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=en" json_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=en" - language: "es" html_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=es" markdown_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=es" json_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=es" - language: "fr" html_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=fr" markdown_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=fr" json_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=pl" markdown_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=pl" json_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=ru" markdown_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=ru" json_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=zh" markdown_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=zh" json_url: "https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=zh" --- # GitHub Desktop 3.6.7 corrige les cas limites qui rendent les worktrees risqués > GitHub Desktop 3.6.7 cible les contrôles parallèles : affichage persistant du worktree courant, gestion sûre des références commençant par un tiret, correction d’un chemin Cygwin et prévention d’un plantage du suivi Git LFS. GitHub Desktop 3.6.7 est une petite version, mais elle s’attaque à un problème très concret : les moments où un client Git graphique doit représenter plusieurs extractions d’un même dépôt. Elle ajoute un réglage qui maintient le worktree courant visible, corrige la gestion des noms commençant par un tiret, répare un problème de chemin avec Open in Cygwin et traite un plantage du suivi de progression de Git LFS. ![Photo éditoriale d’un ordinateur portable et de dossiers de projets organisés représentant plusieurs worktrees Git liés.](https://publicasta.com/storage/projects/10/pages/881/2026/10/b7302cd1-7397-4d9d-94fc-ebfd6382ba07.webp) Rien de tout cela ne modifie la structure fondamentale de GitHub Desktop. Le logiciel reste un client de bureau autour de Git, et non un remplacement du modèle de dépôt de Git. Son apport est plus ciblé : si votre quotidien comporte désormais des branches parallèles, des worktrees liés, de gros fichiers ou des dépôts aux noms peu commodes, la version 3.6.7 retire plusieurs occasions pour l’interface de devenir un obstacle. Cette version mérite donc d’être testée par les responsables de maintenance et les développeurs qui utilisent régulièrement des worktrees. Elle ne justifie pas de modifier sans vérification un flux de travail stable, et ne transforme pas GitHub Desktop en environnement complet de gestion des worktrees. Le journal des modifications et le tag de version du projet décrivent une mise à jour de maintenance ciblée, tandis que la documentation de Git explique pourquoi certaines réserves restantes sont structurelles plutôt que cosmétiques. ## Ce qui change dans la version 3.6.7 Le [tag officiel de la version 3.6.7](https://github.com/desktop/desktop/releases/tag/release-3.6.7) regroupe les changements en quatre catégories. Premièrement, les noms de branches, de dépôts distants et de tags qui commencent par un tiret sont désormais correctement traités lors des opérations de fetch, push, checkout, merge, rebase et worktree. Un nom comme -maintenance est inhabituel, mais les dépôts Git rencontrent effectivement des noms difficiles à transmettre à la frontière de la ligne de commande. Une application graphique doit tout de même les transmettre à Git sans ambiguïté et distinguer une valeur d’une option. Le correctif est important moins parce que les équipes utilisent souvent des noms commençant par un tiret que parce qu’il ferme une catégorie d’ambiguïtés d’entrée dans plusieurs flux à la fois. Deuxièmement, la version corrige l’intégration Open in Cygwin lorsque le dossier du dépôt contient des espaces ou de la ponctuation. C’est le genre de bug qui reste invisible dans un répertoire de test soigneusement nommé, puis devient immédiatement pénible dans un vrai dossier personnel Windows. Le dépôt peut être valide, le shell installé, et l’intégration échouer malgré tout si le chemin est assemblé ou placé entre guillemets de manière incorrecte. La note de version est concise, mais son périmètre est clair : les chemins sont des données, et les intégrations de bureau doivent les préserver exactement. Troisièmement, le suivi de progression de Git LFS ne provoque plus de plantage lorsqu’il rencontre une erreur de lecture de fichier. Cela ne rend pas lisible le fichier concerné et ne dispense pas d’examiner le stockage, les permissions ou un checkout endommagé. En revanche, une erreur de suivi de progression ne devrait plus entraîner le client avec elle. Pour les dépôts qui stockent des binaires, des ressources graphiques, des jeux de données ou d’autres objets volumineux via Git LFS, c’est le correctif le plus directement lié à la fiabilité dans cette version. Enfin, le nouveau réglage d’apparence permet de maintenir visible le segment de barre consacré au worktree courant grâce à l’option Always show worktree list. Le journal des modifications de la version bêta précédente décrit le comportement visé : le contrôle du worktree actuel reste présent au lieu de disparaître lorsque le reste de la liste est réduit. La différence paraît minime jusqu’à ce qu’un dépôt possède plusieurs extractions liées et que l’utilisateur doive confirmer laquelle est active avant de valider. La version apporte aussi les petits ajustements attendus d’une mise à jour de maintenance : un meilleur contraste pour les icônes de réussite et d’échec dans le résumé des vérifications, ainsi que la validation des chemins de bundles d’applications macOS dans la boîte de dialogue de clonage. Ce ne sont pas des fonctions vedettes, mais elles suivent la logique générale de la version 3.6.7 : rendre les conditions limites plus lisibles et moins fragiles. ## Pourquoi le réglage des worktrees compte Les worktrees Git ne sont pas de simples clones supplémentaires. La [documentation de Git sur les worktrees](https://git-scm.com/docs/git-worktree) décrit un arbre de travail principal et zéro ou plusieurs worktrees liés qui partagent la majeure partie des données du dépôt, tout en séparant certains états comme HEAD et l’index. En pratique, un même dépôt peut avoir un checkout sur une branche de fonctionnalité, un autre sur une branche de livraison et un troisième sur une branche d’investigation temporaire, sans télécharger trois fois l’intégralité de la base d’objets. Ce modèle convient particulièrement aux tâches qui imposent de changer souvent de contexte. Un responsable de maintenance peut garder une branche de livraison propre tout en examinant une pull request dans un autre dossier. Un développeur peut laisser un test long ou un serveur local tourner dans un worktree et passer à une correction de bug dans un autre. Les outils de codage automatisé rendent aussi les worktrees plus visibles, car ils créent souvent des checkouts isolés pour des tâches parallèles. L’organisation sur le disque change, mais le problème humain reste le même : plusieurs dossiers ressemblent au même projet, et une erreur peut envoyer une modification au mauvais endroit. Un client qui masque le worktree courant jusqu’à l’ouverture d’un menu ajoute une petite incertitude à chaque action. Cette incertitude est négligeable lorsque le dépôt n’a qu’un checkout. Elle devient coûteuse lorsque les noms se ressemblent, que les branches sont éphémères ou qu’un outil crée des dossiers génériques comme work, app ou checkout. L’affichage persistant ne résout pas à lui seul l’identification. GitHub Desktop doit toujours fournir suffisamment de contexte sur le chemin ou la branche pour distinguer les worktrees, et le suivi des problèmes montre que cette question d’ergonomie reste active. Un problème ouvert propose d’afficher le chemin complet d’un worktree au survol lorsque plusieurs arbres partagent le même nom de dossier final. C’est un rappel utile : maintenir la liste visible améliore la découverte, mais ne constitue pas un système de nommage complet. Il faut donc interpréter ce changement avec mesure. Il rend le contexte courant plus difficile à oublier. Il ne garantit pas que le dossier sélectionné est celui que vous aviez en tête et ne remplace pas la vérification de la branche et du chemin avant une action irréversible. ## La version repose sur les contraintes propres à Git Certaines surprises liées aux worktrees ne peuvent pas être entièrement corrigées dans le client. Git partage volontairement les références et les objets entre les worktrees, tout en conservant un état propre à chaque worktree. La documentation précise que HEAD et l’index sont séparés, mais que de nombreuses références restent partagées. Une branche est normalement extraite dans un seul worktree à la fois, et Git refuse certaines opérations tant que l’utilisateur ne les force pas explicitement. Cette distinction explique pourquoi un worktree peut être peu coûteux tout en exigeant de la discipline. Créer un second checkout ne crée pas un dépôt totalement indépendant. Un fetch peut mettre à jour des références distantes partagées. La configuration peut être commune si la configuration spécifique aux worktrees n’est pas activée. Les hooks, les fichiers générés, les caches de compilation et les fichiers d’environnement peuvent se comporter comme si tous les checkouts appartenaient à un projet plus vaste, même lorsque les dossiers sources sont séparés. Les règles de nettoyage comptent également. Git conserve les informations administratives des arbres liés dans le répertoire worktrees du dépôt. Si quelqu’un supprime le dossier d’un worktree depuis le gestionnaire de fichiers, les métadonnées peuvent rester jusqu’à leur élagage. La méthode prise en charge consiste à utiliser git worktree remove pour un arbre propre, ou git worktree prune après avoir vérifié qu’un arbre manquant a bien disparu. Si un dossier est déplacé manuellement, git worktree repair peut reconnecter les métadonnées. GitHub Desktop peut présenter ces états plus clairement, mais il ne peut pas les modifier sans risque. Un utilisateur qui interprète la liste visible des worktrees comme une liste de clones indépendants peut encore se tromper au sujet des branches partagées, de la configuration ou du stockage des objets. La version doit être utilisée avec le modèle de Git, et non à sa place. ## Le correctif des noms commençant par un tiret concerne l’analyse des arguments Les tirets initiaux sont faciles à écarter comme une convention de nommage que personne ne devrait employer. Cette lecture passe à côté de l’enseignement technique du correctif. Beaucoup de programmes en ligne de commande utilisent un tiret pour introduire des options. Lorsqu’une branche, un dépôt distant, un tag ou un chemin valide commence lui aussi par un tiret, chaque couche qui construit une commande doit préserver la distinction entre une valeur et un indicateur. Un client peut traiter ce cas de plusieurs façons : manipuler soigneusement les tableaux d’arguments, utiliser un marqueur explicite de fin des options lorsqu’il est pris en charge, effectuer une validation, ou combiner ces techniques. Pour l’utilisateur, le résultat important est que les opérations ordinaires ne réinterprètent pas un nom de dépôt comme une option de commande. L’ampleur de la note de version 3.6.7 mérite attention. Le correctif ne se limite pas au checkout. Il couvre fetch, push, merge, rebase et les actions liées aux worktrees, ce qui suggère que la valeur problématique peut circuler par plusieurs chemins de commande. Un dépôt peut sembler normal jusqu’à ce qu’un dépôt distant ou un tag présentant la même forme soit utilisé. Corriger la famille d’opérations vaut mieux que réparer un seul élément de menu visible. Les responsables de maintenance doivent tout de même considérer les noms de références inhabituels comme un test de compatibilité. Si l’automatisation, les scripts de livraison, les hooks d’hébergement ou la documentation d’un projet supposent que chaque nom de branche est un mot conventionnel séparé par des barres obliques, le client de bureau n’est qu’une partie du système. La version 3.6.7 réduit un risque côté client, mais ne rend pas robuste chaque intégration tierce. Une petite matrice de test suffit pour vérifier le comportement sans en faire une expérience sur la production : - Créer un dépôt jetable et une branche dont le nom commence par un tiret. - Tester localement fetch, checkout, merge et rebase avant d’utiliser un dépôt distant partagé. - Essayer un dépôt distant ou un tag de même forme uniquement si la politique du dépôt l’autorise. - Vérifier que les interfaces en ligne de commande et web utilisées par l’équipe interprètent le nom de référence de la même manière. - Supprimer proprement les références de test après la vérification. Il ne s’agit pas de recommander les noms commençant par un tiret, mais de vérifier qu’un dépôt existant aux noms peu commodes reste exploitable. ## Git LFS : un correctif de plantage n’est pas un diagnostic de stockage Git LFS modifie la surface de défaillance d’un dépôt. Git conserve des fichiers pointeurs dans l’historique normal, tandis que le contenu volumineux est géré par un serveur LFS et téléchargé à la demande. Un indicateur de progression se trouve donc entre l’interface utilisateur, le système de fichiers local, le processus Git et le transfert LFS. Une erreur de lecture peut venir des permissions, d’un fichier qui disparaît, d’un antivirus, d’un répertoire monté sur le réseau, d’un disque plein ou d’un problème dans le transfert lui-même. Le changement de la version 3.6.7 concerne la réaction du client à l’une de ces erreurs : le suivi de progression ne doit plus faire planter l’application. C’est utile parce qu’un plantage détruit le contexte. L’utilisateur peut perdre l’état visible de l’opération et devoir déterminer si le transfert s’est terminé, a échoué ou a laissé un fichier partiel. Un client qui reste ouvert peut afficher l’erreur et permettre l’inspection du dépôt. Il serait toutefois incorrect de présenter cela comme une garantie d’intégrité des données LFS. Il s’agit d’une amélioration de résilience dans le chemin de remontée d’état. Après la mise à niveau, les équipes devraient toujours vérifier les opérations sur de gros fichiers avec un dépôt de test ou un checkout sans enjeu, notamment sur les machines qui utilisent des partages réseau, des disques externes, une sécurité de poste stricte ou des permissions inhabituelles. En cas d’échec d’un transfert, vérifiez les éléments de base avant de multiplier les tentatives. Confirmez l’espace disque disponible et les droits d’écriture. Vérifiez que le chemin est local et stable. Consultez les journaux LFS et le point de terminaison configuré pour le dépôt. Validez le checkout avec le processus habituel de compilation ou de contrôle des ressources du projet. Le fait que l’application graphique reste ouverte est utile, mais ne prouve pas que l’objet est complet. La nature open source de GitHub Desktop facilite aussi la traçabilité. Le [dépôt](https://github.com/desktop/desktop) est public, son journal des modifications contient des références aux problèmes, et les métadonnées de l’application indiquent une licence MIT. Cette licence rend le code disponible pour inspection et réutilisation, sous réserve des limitations liées aux marques du projet et des licences des dépendances intégrées. Elle ne constitue pas un contrat de support et ne garantit pas que chaque intégration se comporte de façon uniforme sur toutes les plateformes. ## Open in Cygwin et l’importance peu spectaculaire des chemins Le correctif Cygwin appartient à une catégorie plus large de défaillances des logiciels de bureau : l’application comprend un chemin Windows, le shell cible attend un chemin de type POSIX, et la frontière entre les deux contient des espaces ou de la ponctuation. Un chemin comme un répertoire nommé Open Source ou un dossier contenant des parenthèses est parfaitement ordinaire pour un système de fichiers, mais devient une source fréquente d’erreurs de guillemets dans les lanceurs. Pour les utilisateurs, la question pratique est de savoir si l’intégration réparée correspond à leur organisation réelle des dossiers. Si le dépôt se trouve dans un chemin comportant des espaces, des parenthèses, des crochets, des esperluettes ou des caractères non ASCII, testez l’action du menu après la mise à niveau. Faites-le depuis un dépôt qui n’est pas jetable, mais n’utilisez pas le premier checkout d’une livraison active pour la validation. Confirmez que Cygwin s’ouvre dans le bon dossier et que le shell voit les mêmes fichiers que le client de bureau. Ce changement montre aussi pourquoi les notes de version graphiques peuvent sembler plus modestes que les bugs qu’elles corrigent. La fonction n’est qu’une action de menu. Son échec peut bloquer tout un flux pour les personnes qui utilisent une chaîne d’outils de type Unix sous Windows. Une transmission fiable du chemin relève de l’infrastructure, même si elle ne constitue pas une fonction enthousiasmante. La même prudence s’applique aux scripts lancés depuis le client. Évitez de supposer que le seul répertoire de travail courant suffit comme contexte. Les scripts doivent résoudre la racine du dépôt, gérer les espaces et produire un diagnostic visible lorsque le chemin n’existe pas. L’application peut transmettre un chemin correct ; l’outil appelé doit encore savoir le consommer correctement. ## Qui devrait mettre à jour en premier Le cas le plus convaincant pour une mise à jour rapide concerne le développeur qui utilise plusieurs worktrees liés dans GitHub Desktop, travaille avec Git LFS, utilise Cygwin sous Windows ou manipule des dépôts aux noms de références inhabituels. Ces utilisateurs sont les plus proches des chemins concernés et peuvent vérifier si les correctifs correspondent vraiment à leur flux de travail. Un deuxième groupe réunit les responsables de maintenance qui intègrent des contributeurs utilisant plusieurs systèmes d’exploitation. Une version qui supprime une défaillance liée à un chemin ou à un nom peut réduire la charge de support, mais il reste préférable de publier les versions testées et les attentes de configuration du projet plutôt que de considérer la mise à jour comme une solution universelle. Pour un utilisateur disposant d’un seul checkout sur une machine stable, l’urgence est moindre. Les notes citées ici n’annoncent ni grande fonction nouvelle ni réponse de sécurité. La mise à jour reste raisonnable dans le cadre de la maintenance normale, mais il y a peu d’intérêt à perturber un environnement contrôlé sans vérification de compatibilité. Le déploiement le plus sûr reste progressif : 1. Installer la version 3.6.7 sur une machine représentative du flux réel de l’équipe. 2. Ouvrir un dépôt avec un worktree lié et vérifier que le worktree courant reste visible. 3. Exécuter le flux habituel de branche, commit, fetch, push et pull request. 4. Si nécessaire, tester un transfert LFS et l’action Open in Cygwin depuis un chemin contenant des espaces. 5. Vérifier séparément macOS, Windows et Linux si l’équipe prend en charge plusieurs plateformes. 6. Mettre ensuite seulement à jour la version de référence documentée pour les contributeurs. La version est assez petite pour que ce processus soit rapide. Elle est aussi assez spécifique pour qu’un test de fumée général passe à côté des bugs précis qu’elle corrige. ## Ce que GitHub Desktop n’est toujours pas GitHub Desktop ne remplace pas entièrement la ligne de commande Git. Il ne masque pas la distinction entre un worktree et un clone, et ne peut pas décider si une branche doit être partagée, supprimée, verrouillée ou élaguée. La maintenance avancée d’un dépôt reste du ressort des commandes Git et de la documentation opérationnelle du projet. Ce n’est pas non plus un remplacement complet du terminal Cygwin. L’intégration réparée ouvre un autre environnement ; elle n’unifie pas les sémantiques de chemins Windows et POSIX dans tous les outils. Une équipe qui mélange PowerShell, Git Bash, Cygwin, WSL, des conteneurs et des outils de compilation natifs doit garder explicites ses hypothèses sur les chemins. Ce n’est pas davantage une frontière de sécurité pour le contenu des dépôts. L’ouverture d’un dépôt peut déclencher des hooks, afficher des données non fiables, appeler des outils externes ou interagir avec des identifiants selon le flux utilisé. Les améliorations du journal des modifications sont utiles, mais les précautions habituelles restent pertinentes : examiner les scripts du dépôt, limiter les identifiants, maintenir les dépendances à jour et séparer les checkouts expérimentaux des environnements sensibles. Enfin, open source ne signifie pas que chaque élément de la distribution possède la même licence. Le dépôt identifie l’application comme placée sous licence MIT, tandis que les dépendances et les marques GitHub ont leurs propres conditions. Les organisations qui redistribuent une version modifiée doivent examiner les fichiers de licence du dépôt, les notices tierces et les règles de marque au lieu de traiter l’expression open source comme une conclusion juridique générale. ## Solutions pour les équipes qui utilisent beaucoup de worktrees La première alternative est la ligne de commande Git elle-même. Elle expose le modèle complet des worktrees et constitue la référence pour des opérations comme add, list, lock, move, repair, prune et remove. Une équipe qui dépend fortement des worktrees devrait connaître ces commandes, même si la majorité du travail quotidien passe par une interface graphique. La deuxième est un éditeur ou un IDE offrant une prise en charge explicite des espaces de travail multi-racines et des worktrees. L’avantage est la proximité avec le code, les terminaux, les tests et les outils de langage. En contrepartie, l’interface peut faciliter l’ouverture de plusieurs dossiers tout en donnant moins de visibilité sur l’état Git partagé. Les équipes devraient convenir de conventions de nommage et de libellés d’espaces de travail. La troisième est un gestionnaire dédié de worktrees ou un petit ensemble de scripts shell. Ces outils peuvent imposer une organisation des dossiers, créer des noms prévisibles et supprimer les arbres obsolètes. Ils ajoutent aussi une nouvelle surface de maintenance. Un script pratique sur une machine peut devenir dangereux s’il suppose une organisation particulière, supprime un arbre contenant des modifications ou ignore les verrous et les fichiers non suivis. GitHub Desktop 3.6.7 convient surtout à une équipe qui veut un client visuel pour les opérations GitHub courantes tout en acceptant les règles des worktrees de Git. C’est une couche intermédiaire utile, pas une abstraction qui efface l’état du dépôt. ## Le bilan pratique GitHub Desktop 3.6.7 mérite un test si les worktrees, Git LFS, Cygwin ou des noms de références peu commodes font partie de votre quotidien. Le réglage d’affichage améliore le contexte, le correctif des noms commençant par un tiret ferme une véritable catégorie de problèmes de transmission d’arguments, la réparation Cygwin rend moins fragile une frontière courante des chemins Windows, et le changement LFS empêche une erreur de lecture de fichier de faire tomber le client. Pour les autres utilisateurs, il s’agit d’une mise à jour de maintenance classique, au profil peu dramatique. La version est surtout intéressante comme indicateur des pressions qui s’exercent sur les clients Git de bureau : les checkouts parallèles deviennent ordinaires, les dépôts contiennent davantage de contenu généré et binaire, et les développeurs passent constamment des interfaces graphiques aux environnements de terminal. Installez-la, puis testez les zones limites qui comptent pour votre dépôt. Regardez le worktree actif avant de valider. Gardez visibles la branche et le chemin. Utilisez les commandes worktree de Git pour supprimer ou réparer les dossiers. Considérez le correctif de plantage LFS comme une amélioration de résilience, pas comme une étape de vérification. Cela suffit pour tirer parti de la version 3.6.7 sans lui demander de promettre davantage qu’elle ne le fait. ## Sources - [Notes de version de GitHub Desktop 3.6.7](https://github.com/desktop/desktop/releases/tag/release-3.6.7) — faits, GitHub. - [Journal des modifications de GitHub Desktop](https://github.com/desktop/desktop/blob/development/changelog.json) — faits, GitHub. - [Dépôt source et informations de licence de GitHub Desktop](https://github.com/desktop/desktop) — licence, GitHub. - [Documentation git-worktree](https://git-scm.com/docs/git-worktree) — contexte, projet Git. - [Les worktrees liés sont indiscernables du dépôt principal dans la liste déroulante](https://github.com/desktop/desktop/issues/22211) — discussion, GitHub Issues. - [Afficher le chemin complet d’un worktree au survol](https://github.com/desktop/desktop/issues/22946) — discussion, GitHub Issues.