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:
- Cada complemento tendría su propio repositorio en Gitorious dentro de un proyecto. Por ejemplo, un portlet para mostrar gatitos tendría un
kittens-portlet
repositorio dentro delliferay-portlets
proyecto. - Al crear un nuevo complemento, créelo en una rama nombrada según la versión de Liferay (por ejemplo,
lf5.2
). - 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.) * - 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
). - Una vez en producción, el jefe de la nueva sucursal recibirá una etiqueta como
lf6.0v1
. - 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.2clientcorp
para nuestro cliente "ClientCorp Inc.")
Este es un modelo inusual: no tendría ni master
muchas 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-portlet
luego a kittens-lf6.0-portlet
), cada uno con una master
rama y una develop
rama. El master
siempre estaría listo para el despliegue. (O podría ser al revés master
y stable
, como lo sugirió Steve Losh ).
Esto es muy simple, pero no me gustó este sistema:
- podría resultar en una gran cantidad de repositorios en un proyecto, haciendo que Gitorious sea difícil de navegar.
- El nombre del directorio del proyecto es relevante. Si alguien clona el repositorio en un
kittens-lf6.0-portlet
directorio 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 (nombradokittens-portlet
por ejemplo) se considerarían portlets diferentes (y probablemente faltantes) en un portal actualizado. Un poco de cuidado puede evitarlo, pero preferiría evitarlo. - Las diferentes versiones del mismo complemento se mantendrían separadas. Me rompo el corazón :(
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:
- ¿Cuál sería el mejor modelo? ¿Mi propuesta? ¿La modelo de mi amiga? ¿El sistema tradicional de Vincent Driessen?
- ¿Qué otro modelo de ramificación sugeriría?
- 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, v1
pero aparentemente una etiqueta en git no tiene alcance en la rama, es decir, no podría tener una v1
etiqueta 1 lf5.2
y otra adentro lf6.0
, así que tengo que nombrar el rama. ¿Es correcto, por cierto?
fuente
Respuestas:
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.
fuente
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.
fuente