web-dev-qa-db-fra.com

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

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 la question.)

Ma branche maîtresse de supery porte la balise v1.0 Du projet git subby référencée en tant que sous-module. La branche de supery a appelé one.one Et a changé la référence du sous-module pour qu'elle pointe vers la balise v1.1 De subby.

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

En gros, après avoir exécuté un git pull . master Dans la branche subby, il semble que cela crée des sous-modules supplémentaires.

Avant l'extraction/fusion, j'obtiens la réponse souhaitée de git submodule À 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, des sous-modules supplémentaires sont ajoutés lorsque 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 références de sous-modules indésirables et commettre mes conflits et modifications? Ou y a-t-il un paramètre que je peux utiliser avec mon original git pull Pour ignorer mes sous-modules?

gitbranchgit-submodulesconflict
106
Tyler

Je n'ai pas vu cette erreur exacte avant. Mais je devine le problème que vous rencontrez. Cela ressemble parce que le master et le one.one _ branches de supery contiennent différentes références pour le sous-module subby, lorsque vous fusionnez les modifications de master git ne sait pas quelle référence - v1.0 ou v1.1 - devrait ê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 dans les fusions futures. D'un autre côté, si vous changez fréquemment de références de sous-modules, vous devrez peut-être supporter beaucoup de résolution de conflit.

19
Jesse Hallett

Eh bien, ce n’est pas techniquement la gestion des conflits avec les sous-modules (c’est-à-dire: gardez ceci mais pas ça), mais j’ai trouvé un moyen de continuer à travailler ... et tout ce que je devais faire, c’était faire attention à mon git status sortie 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 du sous-module (maître de caisse, déroulez la balise souhaitée, etc.).

75
Tyler

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 n semblable SO post non plus. C'est donc ce qui a fonctionné pour moi - en gardant à l'esprit 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 en maître et de ma branche locale du projet sur lequel je travaillais:

  1. Courir git status - notez le dossier de sous-modules avec des conflits

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

    git reset HEAD path/to/submodule

  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:

    chemin cd/vers/sous-module 
 sous-module git pour chaque git pull origine SUBMODULE-BRANCH-NAME

  4. Et maintenant, vous pouvez commit et vous remettre au travail.

44
Emma Burrows

Commencez par trouver le hash que vous souhaitez référencer dans votre sous-module. puis courir

~/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.

15
hellatan

J'ai eu ce problème avec git rebase -i Origin/master à une branche. Je voulais prendre la version de maître de la référence de sous-module, alors j'ai simplement fait:

git reset master path/to/submodule

et alors

git rebase --continue

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

10
marathon

A obtenu de l'aide de cette discussion. Dans mon cas le

git reset HEAD subby
git commit

travaillé pour moi :)

3
Mithun Das

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 ça

git reset HEAD linux
1
Kjeld Flarup