Quel est le point de git sous-module init'?
Arrière-plan
Pour remplir un référentiel submodules, un généralement invoque:
git submodule init
git submodule update
Dans cette utilisation, git submodule init
semble faire une seule chose: remplir .git/config
avec des informations qui sont déjà dans .gitmodules
.
Quel est le point?
Ne pouvais pas git submodule update
simplement utiliser les informations de .gitmodules
? Cela permettrait d'éviter à la fois:
- inutile de commande (
git submodule init
); et - un dédoublement inutile des données (
.gitmodules
contenu dans.git/config
).
Question
:
- il y a des cas d'utilisation pour
git submodule init
que je ne sais pas (auquel cas, merci de m'éclairer!); ou d'autre git submodule init
est les fichiers inutiles qui pourraient être abandonnées dans Git, sans aucun dommage.
Qui est vrai?
OriginalL'auteur sampablokuper | 2017-06-05
Vous devez vous connecter pour publier un commentaire.
Imaginer le référentiel a 10 submodules et vous êtes intéressés à seulement 2 submodules de ces. Dans un tel cas, vous pouvez obtenir des mises à jour à partir de seulement ces 2 submodules sur le dépôt distant de temps à autre.
git init
fonctionne bien pour cela, parce que une fois que vous exécutez la commandegit init
pour ces 2 submodules,git submodule update --remote
ne s'applique qu'à eux.Si quelqu'un aime ma réponse, merci de corriger mes fautes d'anglais.
Ajouté deux flux de travail de démonstration.
Workflow1: Submodules sont des bibliothèques qui plusieurs projets d'utilisation.
Je pense que c'est l'une des utilisations les plus courantes.
Vous venez de cloner "mon projet".
Et la surface de sa structure est comme ci-dessous.
Le contenu de .gitmodules
Vous voulez de refactoriser le code
code1.js
les références lib1 et lib2 ce qui signifie que vous n'avez pas besoin de cloner et passer lib3 et lib4. Donc, il suffit de lancer la commande ci-dessous.Voyons maintenant le contenu de
.git/config
Cela signifie quelque chose comme "Prêt à mettre à jour lib1 et lib2 de example.com/demo".
À ce stade, lib1 et lib2 répertoires sont vides.
Vous pouvez cloner et passer lib1 et lib2 avec une seule commande.
Maintenant, vous êtes en mesure de refactoriser
code1.js
sans erreurs d'importation.Submodules sont juste des références à certaines s'engage. Ainsi, lorsque vous voulez mettre à jour les bibliothèques de nouvelles versions, vous devez mettre à jour les références. Vous pouvez le faire par la commande ci-dessous.
Maintenant, vous pouvez voir combien il est utile de seulement initialiser les submodules vous avez besoin.
Flux de travail 2: Chaque sous-module est un projet et un chapiteau projet inclut.
Je suis un fan de cette.
Vous clone "principal-projet".
Et la surface de sa structure est comme ci-dessous.
Vous pouvez voir un dossier nommé "partagé". Il y a une règle dans ce flux de travail: si vous souhaitez utiliser les codes de projet dans votre projet, vous devez créer le projet comme un sous-module de projet.
Je tiens à mettre les classes d'entité dans le répertoire partagé comme ci-dessous.
Retour à la sous-module de flux de travail, Le contenu de .gitmodules est comme ci-dessous.
Cette fois vous voulez revoir certaines de code dans le répertoire partagé de la main-projet et vous savez que seuls les sous-projet1 et sous-project2 référence code partagé ce qui signifie que vous n'avez pas besoin de cloner et de paiement des sous-project3 et sous-projet4. Donc, il suffit de lancer la commande ci-dessous.
Et comme je l'ai mentionné dans workflow1, vous devez exécuter la commande ci-dessous à cloner et à la caisse.
Ferais-je
git submodule update --remote
dans ce cas? Ou même ce que je dois d'initialisation et mise à jour des submodules de refactoriser le code dans le répertoire partagé? Oui, parce que vous devez exécuter les tests dans submodules après la refactorisation du code partagé et si toutes les mises à jour des submodules sont engagés et poussé vers le dépôt distant pendant que vous êtes refactoring, alors vous avez besoin pour recevoir pargit submodule update --remote
.Si quelqu'un aime ma réponse, merci de corriger mes fautes d'anglais.
git submodule init
pourrait être utile dans ce cas d'utilisation. Je n'ai pas encore essayé, mais ont upvoted votre réponse pour me faire une réflexion plus large sur git sous-module flux de travail 🙂 auriez-vous l'esprit en ajoutant un bloc de code illustrant le flux de travail vous avez fait allusion à? Je pense que cela ferait pour une réponse encore plus de valeur pour la communauté. Merci encore 🙂Merci pour la correction de mon anglais. J'ai ajouté deux flux de travail. Je ne suis pas sûr que cela aide quelqu'un de bien.
Nice. Upvoted, merci!
Si vous avez d'autres submodules et veulent juste init + mise à jour de certains des submodules puis le flux de travail devient: [git sous-module init -- ./lib1 ./lib2] et [git sous-module de mise à jour à distance ---- -- recursive ./lib1 ./lib2]. Aussi, vous pouvez utiliser [--merge] ou [--rebase] avec la commande de mise à jour, mais lisez d'abord ce qu'ils font, car ils peuvent éviter un décollement de la tête de la caisse au risque de peut-être une déformation de leur histoire si la TÊTE n'est pas sur la branche de droite cours de mise à jour. Pour l'instant, vous pouvez réparer le détaché à la tête de l'état avec [git sous-module foreach "git checkout master && git pull"] (submodules donc, amusant et facile à utiliser xD)
OriginalL'auteur Nigiri
La lecture de la
git submodule
la documentation, il y est un cas d'utilisation qui apparemment justifie l'existence degit submodule init
autonome de commande.Si un utilisateur qui a cloné un référentiel souhaite utiliser une URL différente pour un sous-module que ce qui est spécifié par l'amont référentiel, alors que l'utilisateur peut:
git config -f .gitmodules submodule.biglib.url=/path/to/it
est plus facile que de modifier le fichier, etgit submodule update --init
est plus facile que les deux étapes lorsque vous êtes heureux avec les valeurs par défaut.OriginalL'auteur sampablokuper