Comment gérer les conflits avec les submodules?
J'ai un git superproject qui fait référence à plusieurs submodules et je suis en train de verrouiller un flux de travail pour le reste de mon projet de travailler à l'intérieur.
Pour cette question, disons que mon superproject est appelé supery
et le sous-module est appelé subby
. (Puis, est une simplification de ce que je suis en train de faire...je ne suis pas vraiment à l'aide de branches pour les versions, mais j'ai pensé qu'il serait plus facile de poser une question.)
Ma branche master de supery
a la balise v1.0
du projet git subby
référencé comme un sous-module. La direction générale de supery
appelé one.one
et changé la référence de la sous-module de point à la balise v1.1
de subby
.
Je peux travailler à l'intérieur de chacune de ces branches sans accroc, mais si j'essaie de mettre à jour le one.one
de la direction, avec les changements de la master
branche de recevoir certains conflits et je ne sais pas comment le résoudre.
Au fond après l'exécution d'un git pull . master
tandis que dans le subby
branche, on dirait qu'il crée des submodules.
Avant le pull/fusion, je reçois la réponse souhaitée à partir de git submodule
de la one.one
branche:
$ git checkout master
$ git submodule
qw3rty...321e subby (v1.0)
$ git checkout one.one
$ git submodule
asdfgh...456d subby (v1.1)
Mais après le pull, il ajoute des submodules quand je lance git submodule
:
$ git pull . master
Auto-merged schema
CONFLICT (submodule): Merge conflict in subby - needs qu3rty...321e
Automatic merge failed; fix conflicts and then commit the results.
$ git submodule
qw3rty...321e subby (v1.0)
asdfgh...456d subby (v1.1)
zxcvbn...7890 subby (v1.1~1)
Comment puis-je supprimer/ignorer les bruits sous-module de références et de s'engager mes conflits et les changements? Ou est-il un paramètre que je peux l'utiliser avec mon original git pull
qui ignore mon submodules?
Vous devez vous connecter pour publier un commentaire.
Je n'ai pas vu exactement la même erreur avant. Mais j'ai une idée de la difficulté que vous rencontrez. Il ressemble parce que la
master
etone.one
branches desupery
contiennent différents refs pour lasubby
sous-module, lorsque vous fusionnez des modifications demaster
git ne sais pas qui ref -v1.0
ouv1.1
, doit être maintenu et suivi par leone.one
branche desupery
.Si c'est le cas, vous devez alors sélectionner la ref que vous voulez et de s'engager à ce que le changement de résoudre le conflit. Ce qui est exactement ce que vous faites avec le réinitialiser commande.
C'est un aspect délicat de suivi des différentes versions d'un sous-module dans les différentes branches de votre projet. Mais le sous-module ref est juste comme n'importe quel autre composant de votre projet. Si les deux branches différentes de continuer à suivre les mêmes sous-module refs après une succession de fusions, puis git doit être en mesure de travailler sur le motif sans lever les conflits de fusion des fusions futures. D'autre part, vous si l'interrupteur sous-module refs fréquemment vous pouvez avoir à mettre en place avec beaucoup de résolution de conflits.
added by us: ../Mono.Cecil
dansgit status
maisgit add
etgit rm
a échoué avecMono.Cecil: needs merge, pathspec 'Mono.Cecil/' did not match any files
parce que c'était juste un dossier vide et git ne gère les fichiers.git checkout
m'a donnéMono.Cecil: needs merge, error: you need to resolve your current index first
,git submodule update
a donnéSkipping unmerged submodule Mono.Cecil
etgit checkout master Mono.Cecil
ENFIN, il fixe. Problème de base: lagit status
suggestion est mauvais, afin de choisir une direction et prendre sa copie du dossier aveccheckout
!git checkout --ours SUBMOD
etgit add SUBMOD
et d'autres, mais enfingit checkout master SUBMOD
fixe le conflit. Ce commentaire devrait probablement être une réponse, pas un commentaire... 🙂Bien, ce n'est pas techniquement la gestion des conflits avec les submodules (c'est à dire: gardez ce mais pas que), mais j'ai trouvé un moyen de continuer à travailler...et tout ce que j'avais à faire était de payer attention à mon
git status
de sortie et de réinitialiser les submodules:Qui serait réinitialiser le sous-module de pré-pull commettre. Qui dans ce cas est exactement ce que je voulais. Et dans d'autres cas où j'ai besoin, les modifications appliquées à la sous-module, je vais traiter avec la norme sous-module des flux de travail (checkout master, tirer vers le bas la balise de votre choix, etc).
J'ai un peu de mal avec les réponses sur cette question et n'a pas eu beaucoup de chance avec les réponses un similaire à ce post soit. Donc, c'est ce qui a fonctionné pour moi - en gardant à l'esprit que dans mon cas, le sous-module a été maintenu par une équipe différente, de sorte que le conflit est venu à partir de différents sous-module versions de master et de ma branche locale du projet, je travaille sur:
git status
- faire une note de la sous-module dossier avec les conflitsRéinitialiser le sous-module pour la version dernière engagé dans la branche:
git reset HEAD path/to/submodule
À ce stade, vous avez un libre de conflit de version de votre sous-module qui vous pouvez maintenant mettre à jour à la version la plus récente dans le sous-module du référentiel:
Et maintenant vous pouvez
commit
et de me remettre au travail.Tout d'abord, trouver le hash vous souhaitez pour votre sous-module de référence. ensuite, exécutez
qui a fonctionné pour moi d'obtenir mon sous-module pour le bon hash de référence et de continuer à faire mon travail sans obtenir davantage de conflits.
J'ai eu ce problème avec
git rebase -i origin/master
à une branche. Je voulais prendre du maître de la version de la sous-module ref, j'ai donc tout simplement fait:git reset master path/to/submodule
et puis
git rebase --continue
Qui a résolu le problème pour moi.
Obtenu l'aide de cette discussion.
Dans mon cas, le
fonctionné pour moi 🙂
Bien Dans mon répertoire parent je vois:
Donc j'ai juste fait ce