Quelles sont les différences conceptuelles entre l'utilisation du sous-module et du sous-arbre git?
Quels sont les scénarios typiques pour chacun?
Quelles sont les différences conceptuelles entre l'utilisation du sous-module et du sous-arbre git?
Quels sont les scénarios typiques pour chacun?
Réponses:
Que faire si je veux que les liens pointent toujours vers la TETE du référentiel externe?
Vous pouvez créer un sous-module pour suivre la TÊTE d'une branche d'un référentiel distant de sous-module, avec:
o git submodule add -b <branch> <repository> [<path>]
. (pour spécifier une branche à suivre)
o git submodule update --remote
qui mettra à jour le contenu du sous-module vers la dernière HEAD de <repository>/<branch>
, par défaut origin/master
. Votre projet principal continuera de suivre les hachages de la TETE du sous-module même s'il --remote
est utilisé.
add -b
et --remote
par la suite sur les commandes de mise à jour, conformément à la documentation de mise à jour du sous - module . Dans ce cas, est-ce -b
vraiment nécessaire pour suivre HEAD of master?
-b
est utilisé pour générer les bonnes métadonnées .gitmodule pour le sous-module (c'est équivalent à a git config -f .gitmodules submodule.<path>.branch <branch>
).
--remote
- --remote
fonctionne également s'il -b
n'a pas été utilisé add
. Dans les deux cas, la mise à jour entraînera une validation dans le référentiel parent hébergeant le sous-module, de sorte que les liens ne pointent pas vraiment "toujours vers la TÊTE" de manière très automatique .... soit je ne l'ai pas compris, soit cette revendication mieux vaut être retiré de la réponse d'origine (?)
La différence conceptuelle est:
Avec les sous-modules git, vous voulez généralement séparer un grand référentiel en plus petits. La façon de référencer un sous-module est de style maven - vous référencez un seul commit à partir de l'autre référentiel (sous-module). Si vous avez besoin d'une modification dans le sous-module, vous devez effectuer une validation / push dans le sous-module, puis référencer la nouvelle validation dans le référentiel principal, puis valider / pousser la référence modifiée du référentiel principal. De cette façon, vous devez avoir accès aux deux référentiels pour la construction complète.
Avec git subtree, vous intégrez un autre référentiel dans le vôtre, y compris son historique. Donc, après l'avoir intégré, la taille de votre référentiel est probablement plus grande (ce n'est donc pas une stratégie pour garder les référentiels plus petits). Après l'intégration, il n'y a pas de connexion à l'autre référentiel et vous n'avez pas besoin d'y accéder, sauf si vous souhaitez obtenir une mise à jour. Cette stratégie est donc davantage destinée à la réutilisation du code et de l'historique - personnellement, je ne l'utilise pas.
git subtree
vous, vous pouvez toujours pousser - si vous le souhaitez - non?
sous-module
poussant un référentiel principal vers une télécommande ne pousse pas les fichiers du sous-module
sous-arborescence
poussant un référentiel principal à distance pousse les fichiers de la sous-arborescence
git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree push -v --tags production refs/heads/master:refs/heads/master