Comment j’ai « commis » changements dans un sous-module git ?

Question

J’ai, dans ma naïveté, mis en place un sous-module git et traitée comme une Subversion externe - c'est-à-dire qu’il est maintenant plein de changements que j’ai réalisé seulement n’ont pas été commis ou qu’il pousse n’importe où.

Y a-t-il un moyen facile de commit/repousser les changements sous-module pour le repo en amont ? Et quelle est la technique recommandée dans Git pour faire du développement simultané sur les référentiels distincts (mais liées) de cette façon ?

Answer 1

Le sous-module est propre pension/travail de la région, avec son propre répertoire .git.

Alors, tout d’abord commit/push des changements de votre sous-module :

Alors Prévenez votre projet principal pour suivre la version mise à jour :

Answer 2

Notez que si vous avez commis un tas de changements dans divers submodules, vous pouvez (ou seront bientôt en mesure d') poussez tout d'un coup (c'est à dire un push de la part du parent repo), avec:

git push --recurse-submodules=on-demand

git1.7.11 ([ANNONCER] Git 1.7.11.rc1) mentionne:

"git push --recurse-submodules" appris à éventuellement regarder dans les histoires de submodules lié à la superproject et le repousser.

Probablement fait après ce patch et l' --on-demand option:

recurse-submodules=<check|on-demand>::

Assurez-vous que tous les sous-module s'engage utilisé par les révisions à être poussé sont disponibles sur un suivi à distance de la branche.

• Si check est utilisé, il doit être vérifié que tous les sous-module s'engage qui a changé dans les révisions pour être poussé sont disponibles sur une télécommande.
  Sinon, le push sera annulée et la sortie avec un état différent de zéro.
• Si on-demand est utilisé, tous les submodules qui a changé dans les révisions pour être poussé sera poussé.
  Si la demande n'a pas été en mesure de pousser toutes les révisions nécessaires, il sera également annulée et la sortie avec un état différent de zéro.

Answer 3

<pre><code></code><p><code></code>pour garder une trace de votre sha1 et vérifier votre sous-modules pointent à ce que vous pensez qu’ils sont.</p></pre>

Answer 4

Vous pouvez traiter un sous-module exactement comme un référentiel commun. Pour propager votre validation juste en amont de changements et de pousser comme vous le feriez normalement dans ce répertoire.

Answer 5

Avant que vous pouvez vous engager et de pousser à, vous avez besoin d'init d'un référentiel de travail de l'arbre pour un sous-module. Je suis à l'aide de la tortue et de faire les choses suivantes:

Vérifiez d'abord s'il existe .git fichier (pas un répertoire)

• si il ya un tel fichier, il contient le chemin vers le supermodule répertoire git
• supprimer ce fichier
• ne git init
• ne git add chemin d'accès à distance à celui utilisé pour les sous-module
• suivez les instructions ci-dessous

Si il y était .git fichier, il y a sûrement a été .répertoire git qui suit locales de l'arbre. Vous avez encore besoin d'une branche (vous pouvez en créer un) ou le commutateur maître (qui parfois ne fonctionne pas). Le mieux à faire est de - git fetch - git pull. N'omettez pas d'aller chercher.

Maintenant vos commits et tire seront synchronisés avec votre origin/master