Comment puis-je "valider" les changements dans un sous-module git? [dupliquer]
Cette question a déjà une réponse ici:
J'ai, dans ma naïveté, mis en place un sous - module git et l'ai traité comme une Subversion externe-c'est-à-dire qu'il est maintenant plein de changements que je viens de réaliser n'ont pas été commis ou poussés n'importe où.
Existe-t-il un moyen facile de valider/pousser le le sous-module revient au repo en amont? Et quelle est la technique recommandée dans Git pour faire du développement simultané sur des dépôts séparés (mais liés) de cette manière?
5 réponses
Le sous-module est son propre repo / work-area, avec son propre répertoire .git.
Donc, commencez par valider/pousser les modifications de votre sous-module:
$ cd path/to/submodule
$ git add <stuff>
$ git commit -m "comment"
$ git push
Ensuite, dites à votre projet principal de suivre la version mise à jour:
$ cd /main/project
$ git add path/to/submodule
$ git commit -m "updated my submodule"
$ git push
Notez que si vous avez commis un tas de changements dans divers sous-modules, vous pouvez (ou serez bientôt en mesure de) pousser tout en une seule fois (ie un push du repo parent), avec:
git push --recurse-submodules=on-demand
Git1.7.11 ([annoncer] git 1.7.11.rc1) mentionne:
"
git push --recurse-submodules" appris à regarder éventuellement dans les histoires de sous-modules liés au superprojet et les pousser.
Probablement fait après ce patch, et les --on-demand option:
--recurse-submodules=<check|on-demand|no>::
Assurez-vous que tous les commits de sous-module utilisés par les révisions à pousser sont disponibles sur une branche de suivi à distance.
- si {[4] } est utilisé, il sera vérifié que tous les commits de sous-module qui ont changé dans les révisions à pousser sont disponibles sur une télécommande.
Sinon, le push sera interrompu et sortira avec un statut différent de zéro.- Si
on-demandest utilisé, tous les sous-modules qui ont changé dans les révisions à pousser seront repoussée.
Si on-demand n'a pas été en mesure de pousser toutes les révisions nécessaires, il sera également abandonné et quitter avec un statut différent de zéro.
Cette option ne fonctionne que pour un niveau d'imbrication. Les modifications apportées au sous-module à l'intérieur d'un autre sous-module ne seront pas poussées.
Vous pouvez traiter un sous-module exactement comme un référentiel ordinaire. Pour propager vos modifications en amont, il suffit de valider et de pousser comme vous le feriez normalement dans ce répertoire.
$ git submodule status --recursive
Est aussi un sauveteur dans cette situation. Vous pouvez l'utiliser et gitk --all pour garder une trace de vos sha1 et vérifier que vos sous-modules pointent vers ce que vous pensez qu'ils sont.
Avant de pouvoir valider et pousser, vous devez initialiser une arborescence de référentiel de travail pour un sous-module. J'utilise tortoise et fais les choses suivantes:
Vérifiez D'abord s'il existe .fichier git (pas un répertoire)
- s'il existe un tel fichier, il contient le chemin d'accès au répertoire git supermodule
- supprimer ce fichier
- faire git init
- est-ce que git ajoute un chemin distant celui utilisé pour le sous-module
- , suivez les instructions ci-dessous
S'il y en avait .fichier git, il y avait hargneux .répertoire git qui suit l'arbre local. Vous avez toujours besoin d'une branche (vous pouvez en créer une) ou passer à master (ce qui ne fonctionne parfois pas). Le mieux à faire est de - git fetch - git pull. Ne pas omettre fetch.
Maintenant vos commits et tire seront synchronisés avec votre origin/master