tout d'abord: je crois que votre question tend à obtenir des réponses fortement opiniâtres et peut être considérée comme hors-sujet ici. Cependant, je n'aime pas que si politique et serait pousser la frontière d'être sur le sujet un peu à l'extérieur, donc je tiens à répondre à la place et espérer que les autres font aussi bien.

sur le tutoriel GitHub que vous avez pointé il y a un lien vers comment utiliser la stratégie de fusion subtree qui donne un point de vue sur les avantages/inconvénients:

la Comparaison des sous-arbre de fusion avec submodules

l'avantage d'utiliser subtree merge est qu'il nécessite moins de charge administrative de la part des utilisateurs de votre dépôt. Il fonctionne avec plus ancien (avant Git v1.5.2) clients et vous avez le code juste après clone.

cependant si vous utilisez sous-modules puis vous pouvez choisir de ne pas transférer les objets submodules . Cela peut être un problème avec la fusion subtree.

aussi, dans le cas où vous apportez des modifications à l'autre projet, il est plus facile de soumettre des modifications si vous utilisez juste des sous-modules.

Voici mon point de vue basé sur ce qui précède:

je travaille souvent avec des gens (=committers) qui ne sont pas des utilisateurs réguliers de git, certains encore (et pour toujours) se battent avec le contrôle de version. Les éduquer sur la façon d'utiliser la stratégie de fusion de sous-modules est fondamentalement impossible. Cela implique les concepts de Remote supplémentaires, de fusion, de branches, puis de tout mélanger en un seul flux de travail. Tirer en amont et pousser en amont est un processus en deux étapes. Depuis branches est difficile à comprendre pour eux, c'est sans espoir.

avec des sous-modules c'est encore trop compliqué pour eux ( sigh ) mais c'est plus facile à comprendre: c'est juste un repo à l'intérieur d'un repo (ils sont familiers avec la hiérarchie) et vous pouvez faire votre poussée et tirer comme d'habitude.

fournir des scripts d'enrubannage simples est plus facile imho pour le workflow submodule.

pour les grandes Super-repos avec de nombreux sous-repos le point de choisir de ne pas cloner les données de certains sous-repos est un avantage important des sous-modules. Nous pouvons limiter cela basé sur les exigences de travail et le disque l'utilisation de l'espace.

le contrôle d'accès pourrait être différent. Je n'ai pas encore eu ce problème, mais si différentes repos nécessitent des contrôles d'accès différents, interdisant effectivement certains utilisateurs de certaines sous-repos, je me demande si c'est plus facile à accomplir avec l'approche sous-module.

personnellement, je ne sais pas quoi utiliser. Je partage donc votre confusion: o]

un vrai cas d'utilisation que nous avons là où le subtree git était un salut:

le produit principal de notre société est très modulaire et développé dans plusieurs projets dans des dépôts séparés. Tous les modules ont leur propre feuille de route. Le produit entier est composé de tous les modules des versions concrètes.

en parallèle la version en béton du produit entier est personnalisée pour chacun de nos clients - branches séparées pour chaque module. La personnalisation doit être parfois dans plusieurs projets à la fois ( cross-module customization ).

pour avoir un cycle de vie de produit séparé (entretien, branches de fonction) pour le produit personnalisé, nous avons introduit git subtree. Nous avons un référentiel git-subtree pour tous les modules personnalisés. Notre personnalisation est un 'git subtree push' quotidien vers tous les dépôts originaux vers les branches de personnalisation.

ainsi, nous évitons de gérer beaucoup de repos et de braches. git-subtree a augmenté notre productivité plusieurs fois!

en fait, Git-sous-arborescence sont les alternatives pour le Git-sous-module approche: Il ya beaucoup d'inconvénients ou plutôt je dirais, vous devez être très prudent tout en utilisant git-submodules. E. g lorsque vous avez" un " repo et à l'intérieur de "un" vous avez ajouté un autre repo appelé "deux" en utilisant des sous-modules. Choses dont vous devez prendre soin:

• lorsque vous changez quelque chose en "deux", vous devez vous engager et pousser à l'intérieur de "deux", si vous êtes dans un répertoire de haut niveau (I. e en "une"), vos modifications n'en surbrillance.

• Lorsqu'un utilisateur inconnu essaie de cloner votre "one" repo, après avoir cloné "one" que l'utilisateur doit mettre à jour les sous-modules pour obtenir les " two "repo

ce sont quelques-uns des points et pour une meilleure compréhension, je vous recommande de regarder cette vidéo: https://www.youtube.com/watch?v=UQvXst5I41I&t=576s

• pour surmonter de tels problèmes subtree approche est inventé. Pour obtenir les bases sur git-subtree, avoir une vue sur ce: https://www.youtube.com/watch?v=t3Qhon7burE&t=772s

• je trouve que l'approche subtree est plus fiable et pratique que les sous-modules :) (Je suis très débutant pour dire ces choses)

santé!

pour ajouter aux réponses ci-dessus, un inconvénient supplémentaire de l'utilisation de subtree est la taille repo par rapport à des sous-modules.

Je n'ai pas de mesures du monde réel, mais étant donné que chaque fois qu'une poussée est faite sur un module, partout où ce module est utilisé obtient une copie de la même modification sur le module parent (quand est ensuite mis à jour sur ces repos).

donc si une base de code est fortement modularisée, cela s'additionnera assez rapidement.

Toutefois, étant donné que les prix du stockage sont toujours en baisse, cela n'est peut-être pas un facteur significatif.