2012-01-26 7 views
6

Tenemos la siguiente configuración: Tres aplicaciones que son similares entre sí con el código común extraído en un marco. Cada aplicación se gestiona en su propio repositorio de git e incluye el marco como un submódulo de git.Flujo de trabajo de Git para diferentes versiones de un marco

El problema es que las aplicaciones ahora se desarrollan en paralelo con las nuevas funciones que se agregan al marco que otras aplicaciones no necesitan para ser compatibles de inmediato. Actualmente tenemos diferentes ramas del marco para todas las aplicaciones. Una aplicación utiliza la rama principal del marco porque la mayoría de las veces las nuevas características se introdujeron por primera vez en esta aplicación.

ramas Framework

  • maestros (utilizado por App A)
  • AppB
  • appC

Cuando una nueva característica se introduce en AppB que necesita cambios en el marco eran estos cambios hecho para ramificar appB. Si estos cambios se necesitaban más adelante en la aplicación A, la rama de aplicación se fusionó en el maestro. Esto significa que todos los cambios en la aplicación B deben combinarse en el maestro.

Este sistema funcionaba pero tenía algunos defectos

  • la fusión de una característica de una rama a otra significaba que teníamos que combinar todos los cambios
  • fácil soltar un seguimiento de lo que se había fusionado ya o lo que va a fusionarse cuando la fusión de una rama a otra
  • Marcado cambios de última hora se hizo utilizando los mensajes de confirmación, lo que hizo el último punto aún más importante

Somos cu actualmente buscando un nuevo flujo de trabajo. Estaba pensar en tener las siguientes ramas

  • maestro
  • appA
  • AppB
  • appC

Así que para cada aplicación una rama y una rama principal que incluye todos los cambios. Cuando se desarrollan nuevas características, se debe crear una rama de características y luego aplicarla al maestro, así como a todas las ramas de la aplicación, la función se necesita de inmediato. Otras aplicaciones pueden fusionar la rama de características cuando más tarde necesiten la característica.

veo los siguientes problemas con este

  • Cómo puedo combinar una rama de la característica en múltiples ramas y sólo combinar los cambios que ocurrieron en la rama. Sé de "git rebase on ..." pero no estoy seguro si puedo usar este comando varias veces.
  • ¿Debo usar git cherry-pick para fusionar funciones en múltiples ramas? Prefiero no hacer esto, porque puedo pensar que esto será propenso a errores cuando no seleccione todos los cambios que se realizaron en una rama de función
  • Cómo hacer un seguimiento de qué característica (rama) se ha aplicado a qué aplicación. ¿Puedo usar branch --no-merge o solo funcionará si las ramas tienen el mismo ancestro?

¿Mi manera propuesta es la mejor manera de lograr esto o debería reconsiderar mi estrategia por completo?

+2

Plata de alta, puede usted por favor actualizar esta pregunta con el flujo de trabajo que terminó la adopción y la forma en que está funcionando. Estoy enfrentando la misma situación y también me he equivocado. Por lo tanto, estoy interesado en lo que has hecho. – BlinkyBill

Respuesta

0

Como se explica en "Git & Working on multiple branches", las dos soluciones prácticas a la hora de aplicar compromete a múltiples ramas (que es lo que se haría con la opción "característica ramas") son:

  • de combinación (que debe permitir para mantener la reutilización de esa rama función, ya que sería un seguimiento de lo que ya ha sido fusionar a un banch específico): un rebase --interactive podría estar en orden para que usted pueda volver a ordenar las confirmaciones, poniendo en primer lugar las que desee combinar y, a continuación, los que aún no estás listo para unirte.
  • cherry-picking (y ahora supports a range of commits), pero siempre have been wary of cherry-picking.
+0

rebase --interactive parece ser una buena herramienta para esto. ¿Hay alguna implicación que deba tener en cuenta al usarla? – sliver

+0

@sliver: única que no debe rebasar una rama ya la cuota (empujados a otro repo) con otras personas (como se detalla en http://stackoverflow.com/a/2825924/6309). En tu caso, eso no debería ser un problema. – VonC

Cuestiones relacionadas