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 stream de travail pour le rest des membres du projet.

Pour cette question, disons que mon superprojet est appelé supery et que le sous-module est appelé subby . (Ensuite, il y a une simplification de ce que j’essaie de faire … Je n’utilise pas les twigs pour les versions, mais j’ai pensé que ce serait plus facile à poser en tant que question.)

La twig v1.0 du projet git subby référencée en tant que sous-module par ma twig principale de supery . La twig de supery appelé one.one et a changé la référence du sous-module pour pointer vers la balise v1.1 de subby .

Je peux travailler dans chacune de ces twigs sans problème, mais si je tente de mettre à jour la twig one.one avec les modifications de la twig master , je reçois des conflits et je ne sais pas comment les résoudre.

Fondamentalement, après avoir exécuté une git pull . master git pull . master alors que dans la twig subby , il semble qu’il crée des sous-modules supplémentaires.

Avant le pull / merge, j’obtiens la réponse souhaitée du git submodule de la twig 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 le pull, il ajoute des sous-modules supplémentaires lorsque je lance le git submodulegit 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 supprimer / ignorer les références de sous-modules indésirables et commettre mes conflits et modifications? Ou existe-t-il un paramètre que je peux utiliser avec mon original git pull pour ignorer mes sous-modules?

Je n’ai pas vu cette erreur exacte avant. Mais j’ai une idée du problème que vous rencontrez. Il semble que les twigs master et one.one de la supery contiennent des références différentes 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 – doit être conservée et suivie par one.one twig 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 twigs de votre projet. Mais le sous-module ref est comme n’importe quel autre composant de votre projet. Si les deux twigs différentes continuent à suivre les mêmes références de sous-modules respectives après des fusions successives, alors git devrait être capable de calculer le modèle sans générer de conflits de fusion lors de futures fusions. Par contre, si vous changez fréquemment de sous-module, vous devrez peut-être résoudre de nombreux conflits.

Eh bien, ce n’est pas techniquement gérer les conflits avec les sous-modules (c.-à-d. Garder ça mais pas ça), mais j’ai trouvé un moyen de continuer à travailler … et tout ce que j’avais à faire était de faire attention à la sortie de mon git status et de réinitialiser 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 appliquées au sous-module, je traiterai celles-ci avec les workflows de sous-module standard (checkout master, déroulez la balise désirée, etc.).

J’ai eu un peu de mal avec les réponses à cette question et je n’ai pas eu beaucoup de chance avec les réponses dans un post SO similaire . Voilà ce qui a fonctionné pour moi – sachant que dans mon cas, le sous-module était entretenu par une équipe différente. Le conflit venait donc de différentes versions de sous-modules dans Master et de ma twig locale sur laquelle je travaillais:

  1. Run git status – notez le dossier du sous-module avec les conflits
  2. Réinitialisez le sous-module sur la dernière version validée dans la twig en cours:

    git reset HEAD path/to/submodule

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

      cd path / to / submodule
     git submodule foreach origine git pull SUBMODULE-BRANCH-NAME 
  4. Et maintenant, vous pouvez commit cela et retourner au travail.

D’abord, trouvez le hash que vous voulez que votre sous-module référence. 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 que mon sous-module atteigne la référence de hachage correcte et que je continue mon travail sans autres conflits.

J’ai eu ce problème avec git rebase -i origin/master à une twig. Je voulais prendre la version master du sous-module ref, donc j’ai simplement fait:

git reset master path/to/submodule

et alors

git rebase --continue

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

J’ai reçu de l’aide de cette discussion. Dans mon cas le

 git reset HEAD subby git commit 

a travaillé pour moi 🙂

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 ..." to unstage) (use "git add ..." to mark resolution) 

Donc je viens de faire ça

 git reset HEAD linux