Comment gérer les conflits avec les sous-modules git?

Question

J'ai un superprojet git qui fait référence à plusieurs sous-modules et j'essaie de verrouiller un flux de travail pour que les autres membres de mon projet puissent y travailler.

Pour cette question, disons que mon superprojet s'appelle supery et que le sous-module s'appelle subby . (Ensuite, c’est une simplification de ce que j’essaie de faire. Je n’utilise pas réellement les branches pour les versions, mais j’ai pensé qu’il serait plus simple de poser une question.)

Ma branche principale de supery a la balise v1.0 du projet git subby référencé en tant que sous-module. La branche de supery appelée one.one et a changé la référence du sous-module pour qu'elle pointe vers la balise v1.1 de sous-code .

Je peux travailler sans accroc dans chacune de ces branches, mais si j'essaie de mettre à jour la branche one.one avec les modifications apportées à la branche maître , je reçois des conflits. et je ne sais pas comment les résoudre.

En gros après avoir lancé un git pull. maître dans la branche subby , il semble créer des sous-modules supplémentaires.

Avant l'extraction / fusion, je reçois la réponse souhaitée de sous-module git à partir de la branche one.one :

$ git checkout master
$ git submodule
qw3rty...321e subby (v1.0)
$ git checkout one.one
$ git submodule
asdfgh...456d subby (v1.1)

Mais après l'extraction, il ajoute des sous-modules supplémentaires lorsque je lance sous-module git :

$ 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 références de sous-modules indésirables et valider mes conflits et modifications? Ou y a-t-il un paramètre que je peux utiliser avec mon git pull original qui ignorera mes sous-modules?

Answer 1

Je n'ai jamais vu cette erreur exacte auparavant. Mais je devine le problème que vous rencontrez. Cela ressemble au fait que les branches master et one.one de supery contiennent des références différentes pour le sous-module subby , lorsque vous fusionnez les modifications de maître , git ne sait pas quel ref - v1.0 ou v1.1 - doit être conservé et suivi par le one.one branche de supery .

Si tel est le cas, vous devez sélectionner la référence souhaitée et valider cette modification pour résoudre le conflit. C’est exactement ce que vous faites avec la commande reset .

Il s'agit d'un aspect délicat du suivi des différentes versions d'un sous-module dans différentes branches de votre projet. Mais la référence de sous-module est comme n'importe quel autre composant de votre projet. Si les deux branches différentes continuent à suivre les mêmes références de sous-modules respectives après des fusions successives, alors git devrait pouvoir élaborer le modèle sans générer de conflits de fusion lors de futures fusions. D'autre part, si vous changez fréquemment de références de sous-modules, vous devrez peut-être supporter beaucoup de résolution de conflits.

Answer 2

Eh bien, ce n'est pas techniquement la gestion des conflits avec les sous-modules (c'est-à-dire: garder ceci mais pas ça), mais j'ai trouvé un moyen de continuer à travailler ... et tout ce que j'avais à faire était de faire attention à mon statut de git affiche et réinitialise les sous-modules:

git reset HEAD subby
git commit

Cela réinitialiserait le sous-module à la validation avant extraction. Ce qui dans ce cas est exactement ce que je voulais. Et dans les autres cas où j'ai besoin des modifications apportées au sous-module, je traiterai celles avec les flux de travaux standard des sous-modules (module de paiement, déroulez la balise souhaitée, etc.).

Answer 3

J'ai eu un peu de difficulté avec les réponses à cette question et je n'ai pas eu beaucoup de chance avec les réponses dans une publication SO similaire . C’est donc ce qui a bien fonctionné pour moi - sachant que dans mon cas, le sous-module était géré par une équipe différente. Le conflit provenait donc de différentes versions de sous-modules dans master et dans ma branche locale du projet sur lequel je travaillais:

1. Exécuter git status - notez le dossier du sous-module en conflit

2. Réinitialisez le sous-module à la dernière version validée dans la branche actuelle:

   git réinitialiser le chemin HEAD / vers / sous-module

3. À ce stade, vous avez une version de votre sous-module sans conflit que vous pouvez maintenant mettre à jour vers la dernière version dans le référentiel du sous-module:

   cd path/to/submodule
   git submodule foreach git pull origin SUBMODULE-BRANCH-NAME

4. Et maintenant, vous pouvez valider et reprendre le travail.

Answer 4

Tout d’abord, recherchez le hash que vous souhaitez référencer dans votre sous-module. puis lancez

~/supery/subby $ git co hashpointerhere
~/supery/subby $ cd ../
~/supery $ git add subby
~/supery $ git commit -m 'updated subby reference'

cela a fonctionné pour moi pour obtenir mon sous-module à la référence de hachage correcte et pour continuer mon travail sans avoir d'autres conflits.

Answer 5

J'ai eu ce problème avec git rebase -i origine / maître dans une branche. Je voulais prendre la version de maître du ref du sous-module, alors j'ai simplement fait:

git réinitialise le chemin principal / du / sous-module

et ensuite

git rebase --continue

Cela a résolu le problème pour moi.

Answer 6

Vous avez de l'aide grâce à cette discussion. Dans mon cas, le

git reset HEAD subby
git commit

a travaillé pour moi:)

Answer 7

Eh bien, dans mon répertoire parent, je vois:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Unmerged paths:
(use "git reset HEAD <file>..." to unstage)
(use "git add <file>..." to mark resolution)

Alors je viens de faire cela

git reset HEAD linux