Mantenimiento de parches / twigs de características para múltiples twigs de desarrollo (y tags) en paralelo

Hemos bifurcado un proyecto en git (hub) y queremos mantener algunos parches en nuestro fork mientras también recreamos esos parches en sus lanzamientos (tags) y twigs de lanzamiento.

Estructura inicial del repository

La estructura ascendente es bastante simple:

origin/trunk A---B---D---F---H---... \ origin/0.9 C---E---G---... | (tag 0.9) 

El problema

El proyecto upstream aumentó la versión de una dependencia en commits A y D pero fueron principalmente por conveniencia y estamos seguros de que podemos mantener una versión de compatibilidad por un time.

trunk_compat una twig de características trunk_compat y utilicé git revert --no-commit trunk_compat git revert --no-commit para crear parches para los commits A y D cuando los necesitamos. Lo he ramificado fuera de origin/trunk

 mine/trunk_compat A*---D* / origin/trunk A---B---D---F---H-... \ origin/0.9 C---E---G---... | (tag 0.9) 

Así que ahora es bastante fácil para mí seguir origin/trunk y mantener mis parches mediante el rebasamiento o la fusión, dependiendo de si publico esto o no.

Nuestro objective es mantener estos parches para ambas twigs ( trunk y 0.9 ) y recrear una versión de lanzamiento de 0.9 (ya que está labelda desde E ).

Y estoy perdido cómo hacer esto correctamente.

  • Necesito una twig 0.9_compat que tenga todos los commits hasta G pero también incluye nuestros parches A* y D* para que podamos poner eso en nuestro server de continuous integration y ver si funciona
  • Necesito una label 0.9_compat que tiene el estado E con A* y D* aplicado.
    • Para hacerlo más complicado, commit E es en realidad un backport de D en la twig 0.9 por lo que nuestro parche D* también debe aplicarse aquí
    • Esta no es una fusión o una rebase adecuada porque el proyecto original está en SVN y este es el espejo git-svn que estamos bifurcando
  • En el futuro, upstream tendrá una twig 0.10 etc. y queremos mantener nuestros parches en esas twigs también

Puedo hacer esto con cherry picking mucho o simplemente aplicando parches manualmente (creo) pero eso no se siente bien y creo que no utilizo git en toda su extensión.

Hay dos maneras en que puede hacer esto, y las obtuvo correctamente: rebase (incluye selección de cereza y parche, el mismo resultado al final) o fusión.

  1. Configure todas las twigs que necesita reparar y aplique los parches ( origin/trunk y origin/0.9_compat ).
  2. Aplicar los parches en las twigs
  3. La diferencia radica solo en la estrategia de mantenimiento , que es git pull (fusionar) vs git pull --rebase (rebase) para estas twigs.

La diferencia entre las estrategias es que para git pull , git intentará fusionar los cambios remotos en tu sucursal local (lo que te dará muchos commit de fusión de git, pero tu parche sha seguirá siendo el mismo) y para git pull --rebase git primero searchá los cambios remotos y solo luego intentará aplicar los cambios locales en la parte superior (lo que da como resultado que el parche cambie después de cada extracción). Yo diría que rebase es más apropiado (este argumento es más fuerte si el repository remoto es originalmente git), porque siempre permanecerás en la CABEZA del proyecto + tus parches, sin un desorder de confluencia de fusión innecesario.