Fusionando una sucursal de grand children en GIT

Estoy en una situación específica y me gustaría get una opinión antes de estropear todas mis sucursales 🙂 Actualmente, tengo esta architecture:

master hotfix development p2 

Recientemente, tuve un problema y tuve que trabajar en la twig de hotfix . Ahora está arreglado y lo fusioné con el master . Por lo general, cuando implemento algo, es de la twig de development , sin embargo, debido a las modificaciones dramáticas de progtwigción, tendré que implementar la twig p2 lugar de la de development . De hecho, los cambios en p2 deben comenzar antes del development (y el development no puede ir antes que el de p2 ).

Implementar p2 no es un problema, pero luego tengo preguntas sobre los próximos pasos.

  1. ¿Es posible fusionar la twig master con la twig p2 (para tener los últimos cambios) sin fusionar primero en el development ?
  2. Si 1 es posible, me gustaría fusionar p2 nuevo en el master una vez que se implemente el código, pero luego, si trato de fusionar el master en el development (para poner los cambios de p2 en development ), ¿harán todos los cambios que hice en p2 se includeá en la fusión? Me temo que no será el caso debido a la primera fusión que hice con el master (ya que su último compromiso se ha realizado después de todos los cambios en p2 ).

Gracias

Solutions Collecting From Web of "Fusionando una sucursal de grand children en GIT"

Respuesta algo más detallada:

Su estado inicial es:

 # sketch 1 : *--A--*--*--*--*--*--*--*--* master \ \ / \ *--*--*--* hotfix \ \ *--*--B--*--*--* development \ *--*--*--* p2 

Puedes fusionar p2 en master:

 # sketch 2 : *--A--*--*--*--*--*--*--*--*-----* master \ \ / / \ *--*--*--* h / \ / \ / *--*--B--*--*--* d / \ / *--*--*--* p2 

Una vez que haya hecho esto, git ha almacenado el hecho de que la confirmación B (y todas las confirmaciones entre A … A..B ) es parte del historial del master .

Luego, cuando decidas fusionar el desarrollo en maestro:

 # sketch 3 : *--A--*--*--*--*--*--*--*--*-----*-----* master \ \ / . / \ *--*--*--* h . / \ . / \ . / *--*--B--*--*--*--*----*--* development \ . *--*--*--* p2 

solo mirará las diferencias entre B..development (en lugar de A..development )


En estos bocetos, p2 se dibuja debajo del development .

Pero a git no le importa esta noción de "abajo".

Desde el punto de vista de git, el sketch 2 es el mismo que:

 # sketch 2': *--*--*--* h / \ *--A--*--*--*--*--*--*--*--*--* master \ / \ *--*--*--* p2 \ / \ / *--*--B--*--*--* d 

Y el sketch 3' puede ser más claro al mostrar cómo git resuelve el nuevo "punto de horquilla" entre el master y el development :

 # sketch 3': *--*--*--* h / \ *--A--*--*--*--*--*--*--*--*--*------* master \ / / \ *--*--*--* / \ / / \ / / *--*--B--*--*--*--*--*--* development