Git repos y trabaja con múltiples controles remotos

Estamos usando git (Gitlab) en un server de desarrollo interno para el trabajo.

Tenemos un proyecto que a menudo actúa como base para una serie de otros proyectos.

Como ejemplo básico, tomaremos un código base (inicio de session, sesiones, events de seguimiento, etc.) y agregaremos un código específico de evento para atender mejor las necesidades de ese evento en particular. Cada evento es su propia implementación y tiene su propio espacio en el server.

¿Cuál es la estrategia preferida para manejar bases de código como esta?

Veo dos opciones:

Opción 1 Bifurcación: para cada implementación, clone el repository base, cambie a una twig específica del evento y luego fusione los cambios amplios del código base (refactorización del código base, etc.) a la sucursal siempre que sea necesario.

Esto parece estar bien, pero un poco desorderado (¿qué pasa cuando hay 200 events?). Alguien que quiere trabajar en el código base termina sacando el código de una tonelada de events a la vez. Estos events a menudo vienen con imágenes, películas, files de sonido, que pueden ser bastante caros en cuanto a los resources.

Opción 2 repositorys separados: para cada implementación, clone el repository, inserte el código específico del evento en su repository propio y extraiga el origen (código base) según sea necesario para fusionar los cambios.

Prefiero la idea del número dos: navegar por el repository será más limpio y más fácil. Mi pantalla de actividad no será un desastre para cada evento y el compromiso con él.

También vale la pena mencionar que cada evento probablemente tendrá al less una twig de desarrollo y producción.

¿Ya hay prácticas establecidas para este escenario?

¿Hay otras / mejores opciones?

Si hay más información que puedo proporcionar, o detalles que expliquen mejor esta situación, por favor pregunte.

Gracias.

Tu opción 2 tiene sentido.

Es similar a bifurcar: su proyecto base es "ascendente", los proyectos dependientes son derivados de él, yendo en direcciones diferentes de forma independiente, "descendente". Al igual que Ubuntu, es la base (ascendente), de la que se derivan Kubuntu, Xubuntu y Edubuntu (descendente). Mucho desarrollo entra en la base y se fusiona en sentido descendente, mientras que algunos desarrollos específicos se aplican solo a los derivados, independientemente entre sí.

Es genial cuando hay una configuration tan limpia en la que los repos indirectos pueden get cambios desde el nivel superior a través de las operaciones de VCS, y no siempre es el caso en la vida real. Funciona así en el ejemplo de Ubuntu, pero el propio Ubuntu se deriva de Debian, y no creo que haya una connection en el nivel de VCS allí.

Tu opción 2 suena bien. Esto es exactamente lo que llamarías un fork en github.

¿Realmente necesita cambiar el código base para cada evento? Tal vez una opción aún más clara sea convertir tu base en una biblioteca y hacer que cada evento solo use esa biblioteca en lugar de include todo el código. – Pero dependiendo de tu idioma y configuration actual esto podría ser un poco de trabajo …