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

taller de resolucion de conflictos para niños

Question

Tengo un superproyecto de git que hace referencia a varios submódulos y estoy intentando 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 intento 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 sub proyecto de git a la que se hace referencia como submódulo. La rama de supery llamó 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 intento actualizar la rama one.one con cambios desde la rama master , recibo algunos conflictos y no sé cómo resolverlos.

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

Antes de la extracción / fusión, obtengo la respuesta deseada del 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 el 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 original git pull que ignorará mis submódulos?

Answer 1

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

Answer 2

Bueno, no está gestionando técnicamente los conflictos con los submódulos (es decir: mantén esto pero no eso), pero encontré la manera de seguir trabajando ... y todo lo que tuve que hacer fue prestar atención a mi salida de git status y reiniciar los 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

Luché un poco con las respuestas sobre esta pregunta y tampoco tuve mucha suerte con las respuestas en una publicación SO similar . 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. Ejecute el git status : anote la carpeta del submódulo con conflictos

2. Restablezca 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 conflicto 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 commit y volver al trabajo.

Answer 4

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

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

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 5

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

git reset HEAD subby
git commit

trabajó para mi :)

Answer 6

Primero, encuentre el hash que desea que su submódulo haga referencia. entonces corre

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

eso me ha funcionado para llevar mi submódulo a la referencia de hash correcta y continuar con mi trabajo sin tener más conflictos.

Answer 7

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

git reset master path/to/submodule

y entonces

git rebase --continue

Eso resolvió el problema para mí.