Flujo de trabajo de Git para el mantenimiento de una bifurcación derivada.

github git-flow

Question

Visión general

Tengo un proyecto que es una personalización de un producto FOSS existente. Se está llegando al punto en el que mantenemos una bifurcación a largo plazo en lugar de aplicar nuevos complementos, etc. Me gustaría algún comentario sobre cuál podría ser el flujo de trabajo más sano para mantener este proyecto.

Criterios

1. Deberíamos poder enviar solicitudes de extracción / parches en sentido ascendente fácilmente
2. El proyecto debe realizar un seguimiento de las versiones etiquetadas y puede actualizarse a las versiones más recientes como parte de nuestro propio flujo de trabajo de la versión.
3. Necesita tener sus propios lanzamientos etiquetados.
4. Necesita tener su propia estructura de ramificación para un proceso de desarrollo similar a git-flow.

Opción 1

Solo bifurca el proyecto en github. Súper desordenado para mantener y poner a la gente al día. falla 3,4.

opcion 2

Cree un nuevo repositorio, haga que un mantenedor del proyecto extraiga las versiones etiquetadas del código base ascendente según sea necesario. por ejemplo, algo como git fetch upstream; git merge upstream/sometag tagintegrationbranch git fetch upstream; git merge upstream/sometag tagintegrationbranch No estoy seguro de cómo empujar fácilmente los arreglos hacia arriba en este modelo. Tipo de falla 1.

Opcion 3

Bifurque el proyecto en sentido ascendente, utilícelo como en sentido ascendente, como en la Opción 2. Se utiliza como auxiliar del sistema de relaciones públicas. Probablemente tendrá que hacer selecciones de cereza o algún tipo de microgestión similar para impulsar la copia de seguridad de este flujo de trabajo en función de la forma en que se manejen las ramas de características / errores, pero debería estar bastante limpio. Parece satisfacer la mayoría de los criterios.

Opción ?

Algo que no he considerado?

Answer 1

La opción 3 parece representar la separación más clara del flujo de trabajo entre los dos proyectos:

• uno con contribución ocasional al proyecto original, con solicitudes de extracción
• Uno con sucursales completamente nuevas y código para la nueva aplicación.

Para facilitar las fusiones, recomendaría el uso de nombres de ramas jerárquicas en su repositorio, para separar claramente:

• Sucursales para el desarrollo de su proyecto (nombres clásicos, sin necesidad de una '' / '')
• ramas desde el repositorio original / original (todas con un nombre que representa a una rama del repositorio original, como '' original/dev '', para que pueda elegir desde o hacia)
  Esas ramas ya están en sus remotos / espacio de nombres en sentido ascendente, pero si desea rechazar nuevos compromisos, necesita crear una rama local, y mi punto es: el nombre de esa rama local debe tener una '' / '' en ella, en Para diferenciarlo claramente con otras sucursales regulares para su proyecto.