Pour quoi utiliser git-worktree?

J'ai lu le post de Github sur git-worktree . Ils écrivent:

Supposons que vous travaillez dans un référentiel Git sur une branche appelée feature, lorsqu'un utilisateur signale un bogue de haute urgence dans master. Vous créez d'abord un arbre de travail lié avec une nouvelle branche, hotfixextrait par rapport au maître […] Vous pouvez corriger le bogue, pousser le correctif et créer une demande d'extraction.

Lorsque je travaille sur une branche appelée fonctionnalité et qu'un bogue de haute urgence est signalé dans master, je cache généralement tout ce sur quoi je travaille et crée une nouvelle branche. Quand j'ai fini, je peux continuer à travailler. C'est un modèle très simple, je travaille comme ça depuis des années.

D'un autre côté, l'utilisation de git-worktree a ses propres limites:

Par exemple, il n'est pas autorisé d'avoir la même branche extraite dans deux arborescences de travail liées en même temps, car cela permettrait aux modifications validées dans une arborescence de travail de mettre l'autre hors de synchronisation.

Pourquoi devrais-je choisir un flux de travail plus compliqué pour un problème qui a déjà été résolu?

Y a-t-il quelque chose git-worktreequi ne pouvait pas être fait à l'avance et qui justifie cette toute nouvelle fonctionnalité complexe?

Pour moi, git worktree est la plus grande amélioration depuis longtemps. Je travaille dans le développement de logiciels d'entreprise. Là, il est très courant de devoir conserver d'anciennes versions comme celles que vous avez publiées il y a 3 ans. Bien sûr, vous avez une branche pour chaque version afin que vous puissiez facilement y basculer et corriger un bug. Cependant, le changement est coûteux, car en attendant, vous avez complètement restructuré le référentiel et peut-être créer le système. Si vous changez, votre IDE fonctionnera fou en essayant d'adapter les paramètres du projet.

Avec worktree, vous pouvez éviter cette reconfiguration constante. Récupérez ces anciennes branches dans des dossiers séparés à l'aide de Worktree. Pour chaque branche, vous avez obtenu un projet IDE indépendant.

Bien sûr, cela aurait pu être fait dans le passé en clonant le dépôt plusieurs fois et c'est mon approche jusqu'à présent. Cependant, cela signifiait également gaspiller de l'espace sur le disque dur et, pire, avoir besoin de récupérer plusieurs fois les mêmes modifications dans le référentiel.

Je peux voir quelques utilisations pour cela.

Si vous disposez d'une suite de tests qui s'exécute pendant une longue période, imaginez des heures et que vous la démarrez, elle bloque efficacement cette copie de travail jusqu'à la fin des tests. Changer de branche pendant ces tests les briserait d'une manière difficile à comprendre.

Ainsi, git-worktreeje pourrais avoir une deuxième idée lancée pour une autre branche qui y travaille.

De plus, lorsque je passe à une autre branche pour effectuer une enquête rapide, mon IDE pense que beaucoup de fichiers ont soudainement changé et indexeront toutes ces modifications, juste pour les réindexer lorsque je reviens.

Un troisième cas d'utilisation serait de faire une comparaison de fichiers en utilisant d'autres outils que git-diff, comme d'habitude diff, entre deux répertoires au lieu de deux branches.

Une utilisation évidente consiste à comparer simultanément le comportement (et non la source) de différentes versions - par exemple différentes versions d'un site Web ou simplement une page Web.

J'ai essayé cela localement.

• créer un répertoire page1.

• à l'intérieur créer le répertoire srcet git initil.

• en srccréer page1.htmlavec un peu de contenu et le valider.

• $ git branch ver0

• $ git worktree add ../V0 ver0

• dans srcmaster, ajoutez plus de texte page1.htmlet validez-le.

• $ git branch sty1

• modifier page1.htmldans la sty1branche (ajouter un style CSS distinctif) et ajouter le valider.

• $ git worktree add ../S1 sty1

Vous pouvez maintenant utiliser un navigateur Web pour ouvrir et afficher ces 3 versions simultanément:

• ..\page1\src\page1.html // tout ce que git a comme courant

• ..\page1\V0\page1.html // la version initiale

• ..\page1\S1\page1.html // la version au style expérimental

1. Il existe des raisons légitimes pour lesquelles vous pouvez souhaiter / avoir besoin de plusieurs postes de travail dans le système de fichiers à la fois.

   • manipuler les fichiers extraits tout en ayant besoin d'apporter des modifications ailleurs (par exemple, compilation / test)

   • différencier les fichiers via des outils de diff normaux

   • pendant les conflits de fusion, je souhaite souvent parcourir le code source car il se trouve du côté source tout en résolvant les conflits dans les fichiers.

   • Si vous devez souvent basculer, vous perdez du temps à vérifier et à revérifier que vous n'avez pas besoin de faire avec plusieurs arbres de travail.

   • le coût mental du changement de contexte mental entre les branches via git stashing n'est pas vraiment mesurable. Certaines personnes trouvent qu'il y a un coût mental à ranger qui n'est pas là en ouvrant simplement des fichiers à partir d'un répertoire différent.

2. Certaines personnes demandent "pourquoi ne pas faire plusieurs clones locaux". Il est vrai qu'avec le drapeau "--local" vous n'avez pas à vous soucier de l'utilisation d'espace disque supplémentaire. C'est (ou des idées similaires) ce que j'ai fait jusqu'à présent. Les avantages fonctionnels des postes de travail liés par rapport aux clones locaux sont les suivants:

   1. Avec les clones locaux, vos arbres de travail supplémentaires (qui se trouvent dans les clones locaux) n'ont tout simplement pas accès aux branches d'origine ou en amont. L '«origine» dans le clone ne sera pas la même que «l'origine» dans le premier clone.

      • Courir git log @{u}..ou git diff origin/feature/other-featurepeut être très utile et ce n'est plus possible ou plus difficile. Ces idées sont techniquement possibles avec des clones locaux via un assortiment de solutions de contournement, mais toutes les solutions de contournement que vous pourriez faire sont mieux et / ou plus simples grâce à des postes de travail liés.

   2. Vous pouvez partager des références entre des arbres de travail. Si vous souhaitez comparer ou emprunter des modifications à une autre succursale locale, vous pouvez maintenant le faire.

tl; dr: Chaque fois que vous voulez faire vérifier deux arbres de travail en même temps pour une raison quelconque, git-worktreec'est un moyen rapide et peu encombrant de le faire.

Si vous créez un autre arbre de travail, la plupart des parties du référentiel (c'est-à-dire .git) seront partagées, ce qui signifie que si vous créez une branche ou récupérez des données pendant que vous êtes dans une arborescence de travail, elles seront également accessibles à partir de toutes les autres arborescences de travail que vous avez. Supposons que vous souhaitiez exécuter votre suite de tests sur branch foo sans avoir à la pousser quelque part pour la cloner, et que vous souhaitiez éviter les tracas du clonage de votre référentiel localement, l'utilisation git-worktreeest un bon moyen de créer simplement une nouvelle extraction d'un état dans un endroit séparé, temporairement ou définitivement. Tout comme avec un clone, tout ce que vous avez à faire lorsque vous en avez terminé est de le supprimer, et la référence à celui-ci sera récupérée après un certain temps.

À l'origine, je suis tombé sur cette question après m'être demandé à quoi pouvaient servir ces fantastiques arbres de travail. Depuis, je les ai intégrés dans mon flux de travail et malgré mon scepticisme initial, je les ai trouvés très utiles.

Je travaille sur une base de code assez grande, ce qui prend un certain temps à compiler. J'ai généralement la branche de développement actuelle sur ma machine ainsi que la branche de fonctionnalités sur laquelle je travaille actuellement plus la branche principale, qui représente l'état actuel du système en direct.

L'un des plus grands avantages pour moi est évidemment que je n'ai pas à recompiler le tout à chaque fois que je change de branche (c'est-à-dire des arbres de travail). Un bon effet secondaire est que je peux aller dans le worktree de développement, y faire des trucs, changer le répertoire en worktree pour ma branche de fonctionnalité actuelle, puis le rebaser sans avoir à tirer en premier.

J'en ai un assez inhabituel: je fais du développement Windows et Linux sur la même machine . J'ai une VirtualBox exécutant Linux à l'intérieur de ma boîte Windows. VirtualBox monte certains répertoires Windows et les utilise directement à l'intérieur de la machine Linux. Cela me permet d'utiliser Windows pour gérer les fichiers mais les construire sous Linux. Il s'agit d'un projet multiplateforme, il s'appuie donc sur Windows et Linux à partir de la même structure de répertoires.

Le problème est que les systèmes de construction Linux et Windows se plantent lorsqu'ils sont utilisés dans le même répertoire; il existe des étapes de construction compliquées pour le téléchargement de bibliothèques, etc., qui utilisent les mêmes noms de répertoire. La version Windows du système de build télécharge les bibliothèques spécifiques à Windows et la version Linux du système de build télécharge les bibliothèques spécifiques à Linux.

Dans un monde idéal, le système de construction serait modifié de sorte que Windows et Linux puissent coexister dans le répertoire, mais pour l'instant, le problème est résolu avec des arbres de travail. Le dossier "Linux" peut générer des artefacts de build spécifiques à Linux et le dossier "Windows" peut générer des artefacts de build spécifiques à Windows. Bien que ce ne soit pas une solution idéale, cela crée un joli trou d'arrêt en attendant que les bogues du système de construction soient résolus.

Certes, worktree n'a pas été conçu pour cela; Je dois garder la version Windows et la version Linux sur des branches distinctes, même si je préfère vraiment qu'elles soient sur la même branche. Pourtant, il fait le travail, et c'est un cas peu conventionnel de worktree sauver la journée.

Dans un nouveau projet pour moi, j'ai créé une fonctionnalité. Mais certaines spécifications ont échoué. Pour comparer les résultats avec masterj'ai créé un work-treedépôt. J'ai comparé les résultats étape par étape dans le code d'exécution, jusqu'à ce que je comprenne ce qui s'est mal passé.

J'utilise git worktreepour le développement d'apprentissage automatique.

J'ai un code fonctionnel principal et je veux ensuite diviser les branches de différentes expériences (différents algorithmes et différents hyperparamètres). git worktreeme permet d'intégrer dvc aux côtés de différentes versions de mon code spécialisées dans différents algorithmes. Après avoir exécuté tous les travaux de formation, j'évalue les mesures finales et fusionne pour maîtriser la meilleure branche / le meilleur modèle.