Todos los commits se pierden al fusionar la twig de desarrollo de nuevo a maestro

Tengo una twig de desarrollo llamada "feature / multientity" que se ramificó desde master. Después de terminar mi trabajo, fusioné la twig de características en una twig de etapas llamada "puesta en escena-combinación de multiedades" que también se bifurcó desde el maestro. Hubo conflictos de fusión que resolví y luego fusioné la twig de escenificación de nuevo en el maestro. Sin embargo, no se combinaron todas las confirmaciones que hice en "feature / multientity". Solo un commit, aquel en el que arreglé los conflictos de fusión, se fusionó. Entonces, aunque el código esté actualizado, cualquier futuro que se fusione desde "feature / multientity" hasta master tendrá conflictos de fusión porque ninguno de los commits fue transferido. ¿Alguien se ha encontrado con este problema antes? Estoy usando SourceTree como mi herramienta de control de versiones.

Me encontré con su problema descrito y estoy usando SourceTree como herramienta de visualización. Resolví el problema al restablecer el estado antes de fusionar y fusionar correctamente. Aparentemente intenté fusionar ambas twigs para dominar dónde debería haber fusionado la twig de entidades en la twig de etapas primero. Esto puede suceder si los nombres de las sucursales no son triviales.

Puede intentar seguir los pasos para combinar los cambios de sucursal de características en la bifurcación de etapas antes de fusionar todos los cambios en maestros:

  1. Función de pago / multientity
  2. Restablecer la característica / multientidad a estado antes de la fusión, usar, por ejemplo, git log --stat para encontrar el hash de confirmación antes de la fusión. Usa git reset --hard commit_hash_here

  3. Repita para la ramificación de etapas, restablezca la fusión de etapas-multienvío al estado antes de la fusión

  4. Ahora git checkout staging-multientity-merge primero y use command git merge feature/multientity aquí solo después de verificar la twig de etapas. Esto traerá cambios desde la característica / multientidad a la twig de etapas.

  5. Utilice el git status para controlar el estado de la fusión y solucione los conflictos de fusión. Commit usando git commit -m "Your merge conflict resolution message here." Ahora su twig de ensayo está list para join al maestro.

  6. Luego, use git checkout master , esto es algo que olvidé, y complete el trabajo usando git merge staging-multientity-merge . Utilice la opción Crear un nuevo compromiso incluso si la opción de avance rápido es posible en la vista de confirmación de SourceTree, (esquina inferior izquierda), esto permitirá que múltiples twigs no apunten en una única confirmación en la vista de confirmación de SourceTree. El uso de no-fast-forward aquí crea una perspectiva visualmente más agradable en la vista del historial de commit de SourceTree, en mi opinión.

Al usar este enfoque, restablecer las twigs puede forzarlo a forzar cambios de inserción en el repository remoto, pero no es necesario si aún no realizó una fusión fallida a remota.

Mientras tenía este problema de fusión fallida, tuve dificultades para interpretar los elementos visuales de la herramienta SourceTree sobre cada twig. Los colors son arbitrarios y están ahí para ayudarlo a visualizar una relación padre-hijo de una confirmación. Consulte la respuesta de la comunidad de Atlassian sobre qué representan las imágenes en color de la twig de la herramienta SourceTree para get más información sobre SourceTree.

No tiene sentido. Cuando observa el compromiso de fusión en puesta en escena-fusión de multientity, ¿ve sus cambios de característica / multientidad? Si es así, están ahí. Si no, ¿cometiste un error durante la resolución del conflicto de combinación y no los incluyes o no completas la fusión con un git add / rm y luego cometes git? Lo mismo para el compromiso de fusión en maestro.