¿Cómo manejo los conflictos con los submódulos de git?

Question

Tengo un superproyecto git que hace referencia a varios submódulos y estoy tratando de bloquear un flujo de trabajo para que el resto de los miembros de mi proyecto trabajen dentro.

Para esta pregunta, digamos que mi superproyecto se llama supery y el submódulo se llama subby . (Entonces, es una simplificación de lo que estoy tratando de hacer ... No estoy usando las sucursales para las versiones, pero pensé que sería más fácil plantearlo como una pregunta).

Mi rama maestra de supery tiene la etiqueta v1.0 del proyecto git subby referenciada como un submódulo. La rama de supery llamada one.one y cambió la referencia del submódulo para que apunte a la etiqueta v1.1 de subby .

Puedo trabajar dentro de cada una de estas ramas sin ningún problema, pero si intento actualizar la rama one.one con cambios de la rama master recibo algunos conflictos y no sé cómo resolverlos.

Básicamente, después de ejecutar un git pull. master mientras se encuentra en la rama subby , parece que crea submódulos adicionales.

Antes de la extracción / fusión, obtengo la respuesta deseada de git submodule de la rama one.one :

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

Pero después de la extracción, agrega submódulos adicionales cuando ejecuto 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)

¿Cómo elimino / ignoro las referencias de submódulos no deseadas y confirmo mis conflictos y cambios? ¿O hay un parámetro que pueda usar con mi git pull original que ignorará mis submódulos?

Answer 1

No he visto ese error exacto antes. Pero tengo una conjetura sobre los problemas que están encontrando. Parece que las ramas master y one.one de supery contienen referencias diferentes para el submódulo subby , cuando fusiona los cambios de master git no sabe qué ref - v1.0 o v1.1 - debe ser guardado y seguido por one.one rama de supery .

Si ese es el caso, entonces debe seleccionar la referencia que desea y confirmar ese cambio para resolver el conflicto. Que es exactamente lo que está haciendo con el comando reiniciar .

Este es un aspecto difícil de rastrear diferentes versiones de un submódulo en diferentes ramas de su proyecto. Pero la referencia del submódulo es como cualquier otro componente de su proyecto. Si las dos ramas diferentes continúan rastreando las mismas referencias de submódulos respectivas después de las sucesivas fusiones, entonces git debería poder resolver el patrón sin generar conflictos de fusión en fusiones futuras. Por otra parte, si cambias las referencias de los submódulos con frecuencia, es posible que tengas que soportar una gran cantidad de resolución de conflictos.

Answer 2

Bueno, no es técnicamente la gestión de conflictos con los submódulos (es decir, mantener esto pero no eso), pero encontré una manera de continuar trabajando ... y todo lo que tenía que hacer era prestar atención a mi git status imprime y restablece los submódulos:

git reset HEAD subby
git commit

Eso restablecería el submódulo a la confirmación previa al arrastre. Que en este caso es exactamente lo que quería. Y en otros casos en los que necesito que los cambios se apliquen al submódulo, los manejaré con los flujos de trabajo de submódulos estándar (registro de salida maestro, desplegar la etiqueta deseada, etc.).

Answer 3

Luché un poco con las respuestas a esta pregunta y no tuve mucha suerte con las respuestas en una publicación SO similar tampoco. Así que esto fue lo que funcionó para mí, teniendo en cuenta que en mi caso, el submódulo fue mantenido por un equipo diferente, por lo que el conflicto provino de diferentes versiones de submódulo en master y mi sucursal local del proyecto en el que estaba trabajando:

1. Ejecutar git status : anote la carpeta de submódulos con conflictos

2. Restablecer el submódulo a la versión que se confirmó por última vez en la rama actual:

   git reset HEAD path / to / submodule

3. En este punto, tiene una versión libre de conflictos de su submódulo que ahora puede actualizar a la última versión en el repositorio del submódulo:

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

4. Y ahora puedes confirmar y volver al trabajo.

Answer 4

Primero, encuentre el hash que desea que su submódulo haga referencia. luego ejecuta

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

ha funcionado para que yo obtenga mi submódulo con la referencia hash correcta y continúe con mi trabajo sin que surjan más conflictos.

Answer 5

Tuve este problema con git rebase -i origin / master en una rama. Quería tomar la versión maestra de la referencia del submódulo, así que simplemente lo hice:

ruta maestra de reinicio de git / to / submodule

y luego

git rebase --continue

Eso me solucionó el problema.

Answer 6

Tengo ayuda de esta discusión. En mi caso el

git reset HEAD subby
git commit

funcionó para mí :)

Answer 7

Bueno, en mi directorio principal veo:

$ 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)

Así que acabo de hacer esto

git reset HEAD linux