Git: enfoque de fusión por partes para los principales cambios de versión?

Estamos trabajando en una revisión importante de nuestro website. Todo el trabajo en el sitio revisado se está haciendo en una twig git (llámelo como 2.0), que se separó del maestro hace algún time. En el path, algunos cambios, menores y significativos, se han hecho para dominar, y nos gustaría fusionar esos cambios en 2.0.

Sin embargo, hacerlo como una combinación grande parece difícil de manejar: mientras que algunos de los cambios se fusionarán muy bien, algunos de ellos implican código que ya no existe en 2.0, y esencialmente requerirán volver a implementar nuevas características en 2.0. Mientras haya un montón de conflictos no resueltos después de la fusión, arreglar esas características puede ser bastante difícil. Hemos considerado usar cherry-pick para traer solo los cambios de master que se fusionarán bien, mientras se implementan manualmente los cambios principales, pero eso causará problemas si alguna vez queremos fusionar todos los cambios en 2.0. dominar.

Idealmente, podría realizar fusiones por partes desde el maestro hasta el 2.0: fusionar un grupo de confirmaciones menores hasta un compromiso particular, luego fusionar un único compromiso mayor y volver a implementar manualmente una nueva característica en particular, luego otra serie, de tal forma que al final, el maestro está completamente fusionado en 2.0. ¿Es este un buen enfoque para esta situación? Si es así, ¿cómo me fusiono a medio path en el maestro, en lugar de hasta la confirmación maestra más reciente? ¿O hay algún otro enfoque mejor que debería tomar?

Sin duda, puede fusionarse en una twig por partes al hacer reference a un hash de confirmación en lugar de un nombre de twig. Así que supongamos que desea fusionarse con una confirmación particular en la línea master , digamos abcd1234 , simplemente puede acceder a su twig 2.0 y ejecutar:

 git merge abcd1234 

Usando este enfoque, puede tomar tantos o tan pocos commits a la vez como desee. Si tienes un conflicto, puedes resolver ese conflicto sin tener que tomarlo todo de una vez.

Si tiene cambios en la twig master que sabe que se relacionan únicamente con un código que no existe en su sucursal y, por lo tanto, están completamente obsoletos, puede ejecutar:

 git merge --strategy=ours bcde2345 

Esto creará una confirmación de fusión para los cambios en el master , pero no cambiará el contenido del tree de lo que están en 2.0 , por lo que los commits se marcarán como fusionados sin hacer realmente nada.