Nota: Mi pregunta está enfocada en mi problema específico (que involucra a Liferay) pero espero que pueda ser útil para cualquier persona que necesite mantener varias versiones de un mismo proyecto en git.

Trabajo en una empresa que escribe muchos complementos para Liferay Portal . Estos complementos (portlets, temas, etc.) suelen ser reutilizables y, por supuesto, deben actualizarse para las nuevas versiones del portal.

Sin embargo, es habitual tener que migrar, digamos, un portlet a una nueva versión de Liferay y para mantener su versión anterior. Además, con frecuencia tenemos que crear personalizaciones muy específicas para algunos clientes, lo que no tiene sentido agregarse a la "versión principal".

Estos requisitos complican nuestro trabajo pero, afortunadamente, podemos asumir algunas simplificaciones. Por ejemplo, los complementos se actualizan con frecuencia por un solo programador a la vez. Es muy raro que se agreguen dos o más funciones a un complemento al mismo tiempo.

Ahora, estamos migrando a Gitorious . Estamos tratando de concebir un modelo de bifurcación para tal escenario.

Mi modelo

Lo que propuse fue:

1. Cada complemento tendría su propio repositorio en Gitorious dentro de un proyecto. Por ejemplo, un portlet para mostrar gatitos tendría un repositorio kittens-portlet dentro del proyecto liferay-portlets .
2. Al crear un nuevo complemento, créelo en una rama nombrada de acuerdo con la versión de Liferay (por ejemplo, lf5.2 ).
3. Cada vez que se realiza una actualización en el complemento, la actualización se aprueba y se implementa en producción, etiquete el complemento con una versión (por ejemplo, lf5.2v1 , lf5.2v2 etc.) *
4. Cada vez que se debe portar un complemento a una nueva versión de Liferay, ramificamos la versión más reciente (creando, por ejemplo, la rama lf6.0 ).
5. Una vez en producción, el jefe de la nueva sucursal recibirá una etiqueta como lf6.0v1 .
6. Cada vez que tenemos que personalizar un complemento de una manera específica del cliente, creamos una rama con el nombre del cliente (por ejemplo, crearíamos una rama lf5.2clientcorp para nuestro cliente "ClientCorp Inc.")

Este es un modelo inusual: no tendría master y muchas ramas que no se fusionan. Así es como supongo un repositorio con dicho modelo se vería así:

Unamigoencontróestesistemabastantecomplejoypropensoaerrores.Sugirióelexcelenteypopular modelo de Vincent Driessen , que aún me resulta más difícil de manejar y disciplinar. -demander Es genial (y probado) por supuesto, pero parece demasiado complejo para nuestra situación.

El modelo de mi amigo

Luego sugirió otro modelo: tendríamos un repositorio para cada complemento en una versión de Liferay (así que comenzaríamos a crear un kittens-lf5.2-portlet y luego un kittens-lf6.0-portlet ), cada uno con una rama master y un develop rama. El master estaría siempre listo para la implementación. (O podría ser al revés, master y stable , como sugiere Steve Losh ).

Esto es muy simple, pero no me gustó este sistema:

1. podría resultar en una gran cantidad de repositorios en un proyecto, haciendo que Gitorious sea difícil de navegar.
2. El nombre del directorio del proyecto es relevante. Si alguien clona el repositorio en un directorio kittens-lf6.0-portlet y genera el WAR con ant (como es habitual), el nombre de WAR también será kittens-lf6.0-portlet . Las versiones anteriores de este portlet (llamadas kittens-portlet por ejemplo) se considerarían como portlets diferentes (y probablemente faltan) en un portal actualizado. Un poco de cuidado puede evitarlo, pero preferiría evitarlo.
3. Las diferentes versiones del mismo complemento se mantendrían separadas. Rompo mi corazón :(
4. kittens-lf6.0-portlet es un nombre feo para un repositorio, creo.

Sospecho que los dos últimos puntos, que son los dos más subjetivos también, son la razón principal de mi falta de voluntad. No obstante, las cuatro objeciones se mantienen.

OTOH, mi propia propuesta me parece extraña y me pregunto si hay errores ocultos en ella. OT3rdH git es tan poderoso y flexible que creo que no debería avergonzarme al explorar sus posibilidades.

Entonces, pregunto:

1. ¿Cuál sería el mejor modelo? ¿Mi propuesta? ¿El modelo de mi amiga? ¿El tradicional sistema de Vincent Driessen?
2. ¿Qué otro modelo de ramificación sugeriría?
3. Si crees que mi modelo es malo, ¿por qué crees? Me encantaría saber cuáles son los inconvenientes y los puntos ciegos.

* En realidad, preferiría etiquetar la confirmación con una versión como v1 pero aparentemente una etiqueta en git no tiene un alcance en la rama, es decir, no podría tener una etiqueta de 1 v1 en lf5.2 y otro en lf6.0 , así que tengo que nombrar la rama. ¿Es correcto por cierto?