Nota: Mi pregunta se centra 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 mantener su versión anterior. Además, con frecuencia tenemos que crear personalizaciones muy específicas para algunos clientes, lo que no tiene sentido agregar a la "versión principal".

Estos requisitos complican nuestro trabajo pero, afortunadamente, podemos asumir algunas simplificaciones. Por ejemplo, los complementos son actualizados frecuentemente 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 ramificació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 kittens-portletrepositorio dentro del liferay-portletsproyecto.
2. Al crear un nuevo complemento, créelo en una rama nombrada según 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.2v2etc.) *
4. Cada vez que un complemento se debe portar a una nueva versión de Liferay, ramificamos la versión más reciente (creando, por ejemplo, la ramificación 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, creamos una rama lf5.2clientcorppara nuestro cliente "ClientCorp Inc.")

Este es un modelo inusual: no tendría ni mastermuchas ramas que no se fusionaran. Así es como supongo que se vería un repositorio con dicho modelo:

Un amigo encontró este sistema bastante complejo y propenso a errores. Sugirió el excelente y popular modelo Vincent Driessen , que encontré aún más difícil de manejar y exigente de disciplina. Es genial (¡y probado!), Por supuesto, pero parece demasiado complejo para nuestra situación.

Modelo de mi amigo

Luego sugirió otro modelo: tendríamos un repositorio para cada complemento en una versión de Liferay (por lo que comenzaríamos a crear ay kittens-lf5.2-portletluego a kittens-lf6.0-portlet), cada uno con una masterrama y una developrama. El mastersiempre estaría listo para el despliegue. (O podría ser al revés mastery stable, como lo sugirió 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 kittens-lf6.0-portletdirectorio y genera el WAR con hormiga (como de costumbre), el nombre WAR también lo será kittens-lf6.0-portlet. Las versiones antiguas de este portlet (nombrado kittens-portletpor ejemplo) se considerarían portlets diferentes (y probablemente faltantes) 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. Me rompo el corazón :(
4. kittens-lf6.0-portlet Es un nombre feo para un repositorio, creo.

Sospecho que los dos últimos puntos, que también son los dos más subjetivos, 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 sentir vergüenza al explorar sus posibilidades.

Entonces pregunto:

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

* En realidad, preferiría etiquetar el commit con una versión como, v1pero aparentemente una etiqueta en git no tiene alcance en la rama, es decir, no podría tener una v1etiqueta 1 lf5.2y otra adentro lf6.0, así que tengo que nombrar el rama. ¿Es correcto, por cierto?

Si leo esto correctamente, las ramas son básicamente una desviación de una sola vez de su línea principal de desarrollo, nunca pretendieron fusionarse nuevamente en la línea principal y los avances en la línea principal nunca se aplicarán a estas ramas. La única desviación sería que las correcciones de errores apropiadas para la versión en la que se basaba la rama deben aplicarse a la rama.

La respuesta ahora gira en torno a su flujo de trabajo diario, la cantidad de desarrolladores que trabajan en cualquier rama o la cantidad de cambios son pistas falsas. Veo su necesidad principal de querer saber qué ramas obtienen una actualización de corrección de errores de un cambio de rama principal y para esto creo que el repositorio combinado con ramas será más eficiente ya que todo está en un solo lugar. Si nunca hubo necesidad de polinización cruzada, los repositorios separados lo harían cumplir, pero ese escenario no coincide con la realidad de su proyecto tal como lo entiendo.

El modelo Driessen funcionaría bien si su proyecto necesitara fusionar las ramas nuevamente en la línea principal de desarrollo, pero no lo necesita. Aun así, creo que hay mérito en mantener un concepto InDevelopment y StableRelease si está trabajando en un producto que está en vivo.

Para resumir, creo que su proyecto funcionaría bien con su modelo de ramificación más una pizca de Driessen para su línea principal. Su experiencia puede ser diferente; Siempre he trabajado con una rama de "lanzamiento pendiente" que se convierte en una rama "en vivo" y una "próxima versión" separada que requieren polinización cruzada de arreglos y cambios en varios puntos, por lo que mi percepción puede estar sesgada.

Lo que me sorprende es el hecho de que cada portlet tiene su propio repositorio (pero su historia puede no estar completa). Personalmente, crearía un repositorio por proyecto. Los proyectos a menudo tienen múltiples portlets y todos se compilan en la misma ejecución contra la misma versión de Liferay. Cada proyecto puede ser un duplicado de un proyecto existente que se construye contra una versión diferente de Liferay, pero solo dividiría un producto si las diferencias son demasiado grandes. Si una compilación funciona contra Liferay 5.1 y 5.2, no dividiría el proyecto. Usaría scripting o Maven (o ambos) para dejar que todo funcione. Usaría un Wiki (o Trello) para la gestión de cada producto y con qué versión de Liferay se puede construir.

Por cierto: soy un programador de Java, especialista en Maven, especialista en construcción y tengo experiencia con Liferay y otros servidores de portal (IBM WebSphere y Glassfish).

Pero esto es solo mis € 0.02.