Pour quoi devrais-je 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 très urgent dansmaster. Tout d'abord, vous créez un arbre de travail lié avec une nouvelle branche,hotfix, extrait par rapport à maître […]. Vous pouvez corriger le bogue, le correctif Push et créer une demande d'extraction.
Lorsque je travaille sur une branche appelée fonctionnalité et que certains bogues de haute urgence sont signalés 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'autre part, utiliser 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 un arbre de travail de désynchroniser l'autre.
Pourquoi devrais-je choisir un flux de travail plus compliqué pour un problème déjà résolu?
Y a-t-il quelque chose à propos de git-worktree qui ne puisse être fait à l'avance et qui justifie toute cette 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à-bas, il est très courant que vous deviez conserver d'anciennes versions comme celle que vous avez publiée 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 bogue. Cependant, la commutation est coûteuse, car entre-temps vous avez complètement restructuré le référentiel et peut-être construit le système. Si vous changez de poste, votre IDE s’exécutera en essayant d’adapter les paramètres du projet.
Avec worktree, vous pouvez éviter cette reconfiguration constante. Vérifiez ces anciennes branches dans des dossiers distincts à l'aide de l'arborescence. Pour chaque branche, vous avez un projet indépendant IDE.
Bien sûr, cela aurait pu être fait par le passé en clonant plusieurs fois le référentiel, et c’est ce que j’ai fait jusqu’à présent. Cependant, cela impliquait également de gaspiller de l’espace disque et, pire encore, de devoir récupérer plusieurs fois les mêmes modifications dans le dépôt.
Il ne manque plus que la version officielle de Git 2.5 pour Windows, mais on espère que le nouveau git pour Windows sera bientôt publié :-) (edit: publié maintenant)
Je peux voir quelques utilisations pour cela.
Si vous avez une suite de tests qui dure longtemps, imaginez des heures, puis démarrez-la. 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.
Donc, avec git-worktree, je pourrais avoir une deuxième idée pour une autre branche travaillant ici.
De plus, lorsque je passe dans une autre branche pour effectuer une enquête rapide, mon IDE pense qu'un grand nombre de fichiers a été modifié soudainement et indexera tous ces changements, juste pour être obligé de les ré-indexer à nouveau lorsque je changerai. retour.
Un troisième cas d'utilisation consisterait à comparer les fichiers à l'aide d'autres outils que git-diff, comme d'habitude diff, entre deux répertoires si deux branches.
Une utilisation évidente consiste à comparer simultanément le comportement (pas la source) de différentes versions, par exemple différentes versions d'un site Web ou simplement d'une page Web.
J'ai essayé ceci localement.
créer un répertoire
page1.à l'intérieur, créez le répertoire
srcetgit initit.dans
srccréerpage1.htmlavec un peu de contenu et le valider.$ git branch ver0$ git worktree add ../V0 ver0dans
srcmaster ajoutez plus de texte àpage1.htmlet validez-le.$ git branch sty1éditez
page1.htmldans la branchesty1(ajoutez du style CSS distinctif) et ajoutez le commettre.$ git worktree add ../S1 sty1
Vous pouvez maintenant utiliser un navigateur Web pour ouvrir et voir 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 de style expérimental
Il existe des raisons légitimes pour lesquelles vous souhaiterez/aurez besoin de plusieurs arbres de travail à la fois dans le système de fichiers.
manipuler les fichiers extraits while besoin d'apporter des modifications ailleurs (par exemple, compilation/test)
diffing les fichiers via des outils de diff normaux
lors de conflits de fusion, je souhaite souvent naviguer dans le code source car il est situé côté source while résolution des conflits dans les fichiers.
Si vous devez beaucoup alterner, il y a une perte de temps perdue et une nouvelle vérification que vous n'avez pas besoin de faire avec plusieurs arbres de travail.
le coût mental de la commutation de contexte mental entre les branches via la mise en cache git n'est pas vraiment mesurable. Certaines personnes trouvent qu'il est très coûteux de stocker des éléments cachés en ouvrant simplement des fichiers à partir d'un répertoire différent.
Certaines personnes demandent "pourquoi ne pas créer plusieurs clones locaux". Il est vrai qu'avec l'indicateur "--local", vous n'avez pas à vous soucier de l'utilisation supplémentaire de l'espace disque. C’est ce que j’ai fait jusqu’à présent (ou des idées similaires). Les avantages fonctionnels des arbres de travail liés par rapport aux clones locaux sont les suivants:
Avec les clones locaux, vos arbres de travail supplémentaires (situés dans les clones locaux) n'ont tout simplement pas accès aux branches Origin ou amont. L'origine du clone ne sera pas identique à l'origine du premier clone.
- Lancer
git log @{u}..ougit 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 chaque solution de contournement que vous pouvez effectuer est améliorée et/ou simplifiée via des arborescences associées.
- Lancer
Vous pouvez partager des références entre des arbres de travail. Si vous souhaitez comparer ou emprunter des modifications d'une autre branche locale, vous le pouvez maintenant.
tl; dr: chaque fois que vous souhaitez vérifier deux arbres de travail en même temps pour quelque raison que ce soit, git-worktree constitue 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.-à-d. .git) seront partagées, ce qui signifie que si vous créez une branche ou récupérez des données alors que vous êtes dans un arbre de travail, celui-ci sera également accessible à partir de tout autre arbre de travail. tu as. Supposons que vous souhaitiez exécuter votre suite de tests sur branch foo sans avoir à le pousser quelque part pour le cloner et éviter le souci de cloner votre référentiel localement, en utilisant git-worktree est un bon moyen de créer simplement une nouvelle commande. d'un État dans un endroit séparé, soit temporairement, soit de façon permanente. Comme avec un clone, tout ce que vous avez à faire quand vous en avez fini est de le supprimer, et sa référence sera effacée après un certain temps.
À l'origine, je suis tombé sur cette question après m'être demandé à quoi ces arbres de travail sophistiqués pouvaient être utilisés. Depuis lors, je les ai intégrées à mon flux de travail et, malgré mon scepticisme initial, je les ai trouvées très utiles.
Je travaille sur une base de code assez volumineuse, qui prend un peu de temps à compiler. J'ai généralement la branche de développement actuelle sur ma machine, ainsi que la branche sur laquelle je travaille et la branche principale, qui représente l'état actuel du système actif.
L'un des plus gros avantages pour moi est évidemment que je n'ai pas à tout recompiler à chaque fois que je change de branche (c'est-à-dire des arbres de travail). Un bel effet secondaire est que je peux accéder à la structure de travail de développement, effectuer des tâches là-bas, changer de répertoire pour la branche de travail de ma branche de fonctionnalité actuelle, puis la rebaser sans avoir à tirer au préalable.
J'en ai un peu inhabituel: je développe Windows et Linux sur le même ordinateur. J'ai une machine virtuelle sous Linux dans ma machine Windows. La 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 des fichiers mais d’être construit sous Linux. Il s’agit d’un projet multiplate-forme, il repose 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épertoires. La version Windows du système de génération télécharge les bibliothèques spécifiques à Windows et la version Linux du système de construction télécharge les bibliothèques spécifiques à Linux.
Dans un monde idéal, le système de construction serait modifié afin que Windows et Linux puissent coexister dans le répertoire, mais pour le moment, le problème est résolu par des arbres de travail. Le dossier "Linux" peut générer des artefacts de construction spécifiques à Linux et le dossier "Windows" peut générer des artefacts de construction spécifiques à Windows. Bien que ce ne soit pas une solution idéale, cela constitue un palliatif pour Nice en attendant que les bogues du système de construction soient traités.
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érerais vraiment qu'elles se trouvent sur la même branche. Néanmoins, cela fait le travail, et c'est un cas un peu non conventionnel d'arbre de travail qui sauve la journée.
Dans le nouveau projet pour moi, j'ai créé une fonctionnalité. Mais certaines spécifications ont échoué. Pour comparer les résultats avec master, j'ai créé un repo work-tree. J'ai comparé les résultats étape par étape dans le code d'exécution, jusqu'à ce que je comprenne ce qui n'allait pas.
J'utilise git worktree pour le développement de l'apprentissage automatique.
J'ai un code fonctionnel principal et je souhaite ensuite scinder des branches d'expériences différentes (différents algorithmes et différents hyperparamètres). git worktree me permet d'intégrer dvc aux côtés de différentes versions de mon code spécialisé dans différents algorithmes. Après avoir exécuté toutes les tâches de formation, j’évalue les mesures finales et les fusionne pour maîtriser la meilleure branche/modèle.