Réponse courte:
cd ProjectFooBarCommoneSubmodule
git checkout master
<Do your editing>
git commit --all -m "Lots of fixes"
git push submodule_origin master
cd ..
git add ProjectFooBarCommoneSubmodule
git commit -m "Bumped up the revision of ProjectFooBarCommoneSubmodule"
git push origin master
Le plus long:
Submodules sont un mécanisme de dépendance, où le projet principal (dire) définit une révision spécifiée dans un sous-projet (disons B), qui sera utilisé dans la construction du projet A. pour que l'outil soit utile le comportement est prévisible à partir d'Un:s point de vue. Les dépendances ne peut pas changer, à moins que quelqu'un décide d'intégrer le changement de projet A. Toutes sortes de mauvaises choses peuvent se produire, ont été le projet B:s automatique des modifications des produits importés, les erreurs de compilation sont probablement les meilleurs, comme pour remarquer la immédiatement les pannes. C'est pourquoi B:s la tête est maintenue en état détaché.
L'état de B est de stocker dans Un (découvrez git submodule status), et une révision de changement doit être fait et commis dans Un, dans l'ordre pour qu'il ait un quelconque effet. C'est ce qui se passe dans l'exemple ci-dessus, Un changement au numéro de révision stockée dans le dépôt, et se cogne la version la plus récente. Le processus devra être répété dans les autres grands repo, donc pas automatique "utiliser le maître" de l'interrupteur autant que je sache.
BTW. Le Git chapitre de livre sur submodules et le sous-module de la page de manuel contient de nombreuses informations utiles à propos de submodules, comme l'utilisation normale et typique de pièges. La peine de vérifier.
EDIT: je vais essayer de vous l'expliquer mieux
J'ai pris la liberté de créer des exemples de projets sur mon compte github. Les commits sont vides de sens et contiennent des cochonneries, mais le programme d'installation doit être fine. S'il vous plaît vérifier à suivre.
Les deux ProjectFoo et ProjectBar partager le code dans la commune de la sous-module.
ProjectFooBarCommoneSubmodule:maître est 6850e4e4c1fac49de398
Dans ProjectFoo:
git submodule status
-6850e4e4c1fac49de39890703f21486ca04b87a0 commune
Dans ProjectBar:
git submodule status
-6850e4e4c1fac49de39890703f21486ca04b87a0 commune
Donc, à la fois point de la même révision, droit? L'astuce ici est de voir, que ProjectFoo et ProjectBar point de la révision (6850e4e4c1fac49de39890703f21486ca04b87a0) pas la branche (master), bien qu'ils soient la même chose. Le premier est un décollement de la tête, et de l'autre une branche nommée.
Si vous voulez faire une fixation sur ProjectFooBarCommoneSubmodule, vous pouvez aller dans le sous répertoire dans, par exemple, ProjectFoo, et de choisir la branche de la révision:
git checkout master
<Do your coding and pushing here>
Ensuite un répertoire et de contrôler git sous-module de statut. Il devrait vous dire, que vous êtes maintenant hors de la synchronisation. E. g
git submodule status
+e24bd2bf45d52171a63b67ac05cd4be0ac965f60 commun (heads/master-1-ge24bd2b)
Maintenant, vous pouvez faire un git add, pour définir la référence à ce commit(ge24bd...), validez, et après cela, le sous-module des points de référence à cette révision, qui se trouve également être le maître sur ProjectFooBarCommoneSubmodule.
Maintenant, vous devez mettre à jour la référence en ProjectBar ainsi. Aller à ProjectBar/commun, et ne git fetch origin (ce qui est une avance rapide de fusion), ne
git checkout master
cd ..
git add common
git commit -m "Bumped up the revision"
git push origin master # to publish the revision bump to everybody else
Donc, comme avec n'importe quel dépôt git, vous n'avez pas besoin de travailler sur un décollement de la tête. Vous pouvez travailler sur le master, ou de créer une branche nommée. De toute façon, assurez-vous que l'amont contient les ProjectFooBarCommoneSubmodule changements, ou vous briser à la fois ProjectFoo et ProjectBar, si elles font référence à quelque chose qui n'existe pas. Espérons que cela explique mieux
