Quand utiliser git subtree?
Quel problème est-ce que git subtree résout? Quand et pourquoi devrais-je utiliser cette fonctionnalité?
J'ai lu qu'il est utilisé pour la séparation de référentiel . Mais pourquoi ne créerais-je pas simplement deux référentiels indépendants au lieu de coller deux référentiels indépendants dans un seul?
Ce tutoriel sur GitHub explique comment effectuer une fusion de sous-arbre Git .
Je sais en quelque sorte comment l'utiliser, mais pas quand (cas d'utilisation) et pourquoi, et comment cela se rapporte à git submodule . J'utilisais des sous-modules lorsque je dépendais d'un autre projet ou d'une autre bibliothèque.
Veillez à noter explicitement ce dont vous parlez lorsque vous utilisez le terme 'subtree' dans le contexte de git car il existe en fait deux sujets distincts mais liés:
git-subtree et stratégie de fusion des sous-arbres git .
Le TL; DR
Les deux concepts liés aux sous-arbres vous permettent efficacement de gérer plusieurs référentiels en un. Contrairement à git-submodule où seules les métadonnées sont stockées dans le référentiel racine, sous la forme .gitmodules , et vous devez gérer les référentiels externes séparément.
Plus de détails
La stratégie de fusion de la sous-arborescence git est la méthode la plus manuelle qui utilise les commandes que vous avez référencées.
git-subtree est un script shell pour faciliter une syntaxe plus naturelle. En fait, cela fait toujours partie de contrib et n’est pas complètement intégré à git avec les pages de manuel habituelles. La documentation est plutôt stockée à côté du script.
Voici les informations d'utilisation:
NAME
----
git-subtree - Merge subtrees together and split repository into subtrees
SYNOPSIS
--------
[verse]
'git subtree' add -P <prefix> <commit>
'git subtree' add -P <prefix> <repository> <ref>
'git subtree' pull -P <prefix> <repository> <ref>
'git subtree' Push -P <prefix> <repository> <ref>
'git subtree' merge -P <prefix> <commit>
'git subtree' split -P <prefix> [OPTIONS] [<commit>]
J'ai rencontré pas mal de ressources sur le sujet des sous-arbres, car je comptais écrire mon propre blog. Je mettrai à jour ce post si je le fais, mais pour l'instant voici quelques informations pertinentes à la question posée:
Une grande partie de ce que vous recherchez se trouve sur ce blog Atlassian par Nicola Paolucci la section pertinente ci-dessous:
Pourquoi utiliser subtree au lieu de submodule?
Il y a plusieurs raisons pour lesquelles
subtreevaut mieux utiliser:
- La gestion d'un flux de travail simple est facile.
- Les versions plus anciennes de
gitsont prises en charge (même avantv1.5.2).- Le code du sous-projet est disponible juste après la fin de la
clonedu super projet.subtreene demande pas aux utilisateurs de votre référentiel d’apprendre quoi que ce soit de nouveau, ils peuvent ignorer le fait que vous utilisezsubtreepour gérer les dépendances.subtreen'ajoute pas de nouveaux fichiers de métadonnées comme le faitsubmodules(c'est-à-dire ..gitmodule).- Le contenu du module peut être modifié sans avoir un copie distincte du référentiel de la dépendance quelque part ailleurs.
À mon avis, les inconvénients sont acceptables:
- Vous devez en savoir plus sur une nouvelle stratégie de fusion (c'est-à-dire
subtree).- La contribution de code
upstreamaux sous-projets est légèrement plus compliquée.- La responsabilité de ne pas mélanger les codes de super-projet et de sous-projet dans les commits vous incombe.
Je suis d'accord avec beaucoup de cela aussi. Je recommanderais de consulter l'article car il passe en revue certains usages courants.
Vous avez peut-être remarqué qu'il a également écrit un suivi ici où il mentionne un détail important laissé de côté avec cette approche ...
git-subtree ne parvient pas à inclure la télécommande!
Cette myopie est probablement due au fait que les gens ajoutent souvent une télécommande manuellement lorsqu'il s'agit de sous-arbres, mais cela n'est pas non plus stocké dans git. L'auteur détaille un correctif qu'il a écrit pour ajouter ces métadonnées au commit que le git-subtree génère déjà. Jusqu'à ce que cela devienne la ligne principale officielle de git, vous pouvez faire quelque chose de similaire en modifiant le message de commit ou en le stockant dans un autre commit.
Je trouve aussi cet article de blog très informatif aussi. L'auteur ajoute une troisième méthode de sous-arbre qu'il appelle git-stree au mélange. L'article mérite d'être lu car il fait un très bon travail de comparaison des trois approches. Il donne son opinion personnelle sur ce qu'il aime et ce qu'il n'aime pas et explique pourquoi il a créé la troisième approche.
Extras
Pensées finales
Cette rubrique présente à la fois la puissance de git et la segmentation qui peut se produire lorsqu'une fonctionnalité manque tout juste.
J'ai personnellement développé un dégoût pour git-submodule car je trouve plus difficile à comprendre pour les contributeurs. Je préfère également conserver TOUTES de mes dépendances gérées au sein de mes projets afin de créer un environnement facilement reproductible sans essayer de gérer plusieurs référentiels. git-submodule, cependant, est beaucoup plus connu actuellement, il est donc bon d’en être conscient et dépend de votre auditoire qui peut influencer votre décision.
Premier point: je pense que votre question a tendance à susciter des réponses très critiques et peut être considérée comme hors sujet ici. Cependant, je n'aime pas cette politique SO et j'aurais tendance à repousser un peu la frontière entre sujets, donc j'aime bien répondre à la place et espérer que les autres le font aussi.
Dans le tutoriel GitHub que vous avez indiqué, vous trouverez un lien vers Comment utiliser la stratégie de fusion de sous-arbres qui donne un point de vue sur les avantages/inconvénients:
Comparaison de la fusion de sous-arbres avec des sous-modules
L'avantage d'utiliser fusion d'arborescence est qu'elle nécessite moins de charge administrative des utilisateurs de votre référentiel. Il fonctionne avec Plus ancien (avant Git v1.5.2) clients et vous avez le code juste après cloner.
Toutefois, si vous utilisez sous-modules, vous pouvez alors choisir de ne pas transférer les objets de sous-module}. Cela peut être un problème avec la fusion des sous-arbres.
De même, si vous apportez des modifications à l'autre projet, il est plus facile de soumettre des modifications si vous utilisez uniquement des sous-modules.
Voici mon point de vue basé sur ce qui précède:
Je travaille souvent avec des personnes (= committers) qui ne sont pas des utilisateurs git, certains ont encore (et auront toujours) des difficultés avec le contrôle de version. Leur apprendre à utiliser la stratégie de fusion de sous-modules est fondamentalement impossible. Cela implique les concepts de télécommandes supplémentaires, de fusion, de branches, puis de tout mélanger en un seul flux de travail. Tirer de l'amont et pousser en amont est un processus en deux étapes. Comme les branches sont difficiles à comprendre pour eux, tout cela est sans espoir.
Avec les sous-modules, c’est encore trop compliqué pour eux (sigh) mais c’est plus facile à comprendre: c’est juste un repo dans un repo (ils connaissent la hiérarchie) et vous pouvez pousser et tirer comme d'habitude.
Fournir des scripts de wrapper simples est plus facile à imho pour le flux de travail de sous-module.
Pour les grandes superpositions comportant de nombreuses sous-pensions, le point de choisir de ne pas cloner les données de certaines sous-pensions est un avantage important des sous-modules. Nous pouvons limiter cela en fonction des exigences professionnelles et de l'utilisation de l'espace disque.
Le contrôle d'accès peut être différent. Nous n’avons pas encore eu ce problème, mais si des pensions différentes exigent des contrôles d’accès différents, interdisant effectivement certains utilisateurs de certaines sous-pensions, je me demande si c’est plus facile à réaliser avec l’approche des sous-modules.
Personnellement, je ne sais pas quoi utiliser moi-même. Je partage donc votre confusion: o]
Un cas d'utilisation réel que nous avons où git sous-arbre était un salut:
Le produit principal de notre société est de haute qualité modulaire et développé dans plusieurs projets dans des référentiels distincts. Tous les modules ont leur feuille de route séparée . Le produit entier est composé de tous les modules de versions concrètes.
En parallèle, la version concrète du produit complet est personnalisée pour chacun de nos clients - des branches distinctes pour chaque module. La personnalisation doit être faite parfois dans plusieurs projets à la fois (cross-module customization).
Pour avoir un cycle de vie de produit séparé (maintenance, branches de fonctionnalités) pour un produit personnalisé, nous avons introduit git subtree. Nous avons un référentiel git-subtree pour tous les modules personnalisés. Nos personnalisations sont des «sous-arborescences git» de tous les jours dans tous les référentiels d'origine vers les branches de personnalisation.
De cette manière, nous évitons de gérer beaucoup de pensions et de braches. git-subtree a augmenté notre productivité plusieurs fois!
Fondamentalement, Git-sous-arbre sont les alternatives pour l’approche Git-sous-module: Il ya beaucoup d’inconvénients ou plutôt, je dirais, vous devez faire très attention lorsque vous utilisez des sous-modules git. Par exemple, lorsque vous avez "un" référentiel et dans "un", vous avez ajouté un autre référentiel appelé "deux" à l'aide de sous-modules. Choses dont vous avez besoin de prendre soin:
Lorsque vous modifiez quelque chose en "deux", vous devez valider et pousser dans "deux". Si vous êtes dans le répertoire de niveau supérieur (c'est-à-dire dans "un"), vos modifications ne seront pas mises en surbrillance.
Lorsqu'un utilisateur inconnu tente de cloner votre référentiel "one", après avoir cloné "un", cet utilisateur doit mettre à jour les sous-modules pour obtenir le référentiel "deux".
Voici quelques points à retenir. Pour une meilleure compréhension, je vous recommande de regarder cette vidéo: https://www.youtube.com/watch?v=UQvXst5I41I&t=576s
Pour surmonter ces problèmes, l’approche sous-arbre est inventée. Pour en savoir plus sur git-subtree, consultez-le: https://www.youtube.com/watch?v=t3Qhon7burE&t=772s
Je trouve que l'approche de sous-arbre est plus fiable et pratique que les sous-modules :) (je suis très novice pour dire ces choses)
À votre santé!
Pour ajouter aux réponses ci-dessus, un inconvénient supplémentaire de l’utilisation de subtree est la taille du repo par rapport aux sous-modules.
Je n'ai pas de métrique réelle, mais étant donné que chaque fois qu'un Push est effectué sur un module, partout où ce module est utilisé, une copie du même changement est apportée sur le module parent (lorsqu'elle est ensuite mise à jour sur ces pensions).
Donc, si une base de code est fortement modulaire, cela s’ajoutera assez rapidement.
Cependant, étant donné que les prix de stockage ne cessent de baisser, cela peut ne pas être un facteur important.