¿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 hay una simplificación de lo que estoy tratando de hacer ... En realidad, no estoy usando las ramas para las versiones, pero pensé que sería más fácil plantearlo como una pregunta.)

Mi rama principal de supery tiene la etiqueta v1.0 del proyecto git subby al que se hace referencia como submódulo. La rama de supery llamó a 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 problemas, pero si trato de 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 estaba en la rama subby, parece que crea submódulos adicionales.

Antes del tirón/fusión, me da 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 retirada, se añade submódulos adicionales cuando corro 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ódulo 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 el problema que estás enfrentando. Parece que debido a que los master y one.one ramas de supery contienen diferentes referencias para el submódulo subby, cuando se fusiona cambios de master git no sabe qué ref - v1.0 o v1.1 - deberán mantenerse y seguimiento por parte de la rama one.onesupery.

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

Este es un aspecto complicado de rastrear diferentes versiones de un submódulo en diferentes ramas de su proyecto. Pero la ref del submódulo es como cualquier otro componente de su proyecto.Si las dos ramas diferentes continúan rastreando los mismos refs del submódulo respectivos después de las fusiones sucesivas, entonces git debería ser capaz de resolver el patrón sin aumentar los conflictos de fusión en futuras fusiones. Por otro lado, si cambia las referencias de los submódulos con frecuencia, tendrá que soportar mucha 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 seguir trabajando ... y todo lo que tenía que hacer era prestar atención a mi salida git status y reiniciar el submódulos:

git reset HEAD subby 
git commit 

Eso restablecería el submódulo a la confirmación previa a la extracción. Que en este caso es exactamente lo que quería. Y en otros casos en que necesito los cambios aplicados al submódulo, manejaré aquellos con los flujos de trabajo de submódulo estándar (maestro de pago, despliegue la etiqueta deseada, etc.).

Answer 3

Primero, encuentre el hash que desea que su submódulo haga referencia. a continuación, ejecutar

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

que ha trabajado para mí conseguir mi submódulo a la referencia a un hash correcto y continúo con mi trabajo sin obtener ningún conflictos adicionales.

Answer 4

Luché un poco con las respuestas sobre esta pregunta y tampoco tuve mucha suerte con las respuestas en a similar SO post. Así que esto es lo que funcionó para mí, teniendo en cuenta que en mi caso, el submódulo lo mantenía un equipo diferente, por lo que el conflicto provenía de diferentes versiones de submódulos en master y en mi rama local del proyecto en el que estaba trabajando:

1. Run git status - hacer una nota de la carpeta submódulo con conflictos

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

   git reset HEAD path/to/submodule

3. en este poi nt, tiene una versión libre de conflictos de su submódulo, que ahora se puede actualizar a la versión más reciente en el repositorio del submódulo:

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

4. Y ahora puede que commit y volver al trabajo.

Answer 5

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

git reset master path/to/submodule

y luego

git rebase --continue

que solucionó el problema para mí.

Answer 6

Obtuve ayuda en esta conversación. En mi caso el

git reset HEAD subby 
git commit 

trabajó para mí :)

Answer 7

bien en mi directorio padre que ver:

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

git reset HEAD linux