Enfoque Git para múltiples repositorys con 99% el mismo código

Tenemos un proyecto (es Drupal, pero no creo que esto pueda influir en la respuesta) que tenemos que implementar en 6 países. Nada extrańo acerca de eso.

Pero aquí está el truco. Todos los 6, llamémoslos "versiones", tienen un código ligeramente diferente. Es decir, no todas las lógicas, templates, preprocesss, esquemas de bases de datos, … tienen que aplicarse en las 6 plataforms. Por lo tanto, tenemos 6 repositorys separados en BitBucket. Pero estas diferencias son solo la minoría. El 99% del código es aplicable para todas las plataforms.

En otras palabras, si tenemos un error general , necesitamos arreglarlo y copyrlo / pegarlo manualmente en los otros 5 repositorys. Si tenemos una request de tema / function específica del país, solo se aplicará a ese repository específico.
El time que pasamos en esto y el margen de error son altos, así que estamos buscando una mejor solución.

¿Cuál sería su consejo para mantener estos repositorys sincronizados para las características generales y, sin embargo, no sincronizados para el código específico del país?

Tal vez tenemos que hacer algún script de implementación que sincronice el repository en algún gancho "posterior a la compilation". ¿Hay alguna herramienta (de terceros) que creas que puede ayudarnos? ¿O simplemente necesitamos revisar nuestro git-flow e intentar solucionarlo todo con solo un repository?

Puedes usar las twigs de git para este escenario. Sugiero el siguiente layout de twig:

  • Tienes una twig que actúa como una twig "base".
  • todas las "versiones" específicas tendrán sus propias twigs que se basarán en esta twig.

El flujo de trabajo básico será el siguiente:

  • Cuando tiene un cambio para una "versión" específica, lo hace en la twig específica.
  • Cuando tiene un cambio para todas las "versiones", realiza este cambio en la twig "base" y fusiona (o vuelve a establecer la base) con todas las twigs de "versión" específicas.

Una ideia tiene una twig central que conserva ese 99% de código común y, en lugar de tener 6 repositorys separados, tiene 6 twigs creadas desde esa twig central (llamemos a estas twigs version6 , version6 , …, version6 ).

Entonces, cuando necesite corregir un error en la parte común, solo necesita hacer los cambios en la twig central y volver a establecer la base de estos cambios en cada twig para una versión determinada. Por ejemplo, para la version1 :

 git checkout version1 git rebase central 

Entonces sincronizaría todas estas twigs con cambios de la twig central de una manera fácil (y este process puede automatizarse fácilmente).

Específico para Drupal, podría considerar poner todos sus proyectos de país en un gran repository sin duplicación de código. Use la function de sitios múltiples de Drupal o un module personalizado para manejar lo que se carga en cada país. Esta es probablemente la solución más simple.

De lo contrario, he resuelto este problema de una de dos maneras dependiendo del proyecto.

Mi preference, si el lenguaje y el marco del proyecto lo hacen posible, es poner el código común en un repository que se incluye como una dependencia del package de cada proyecto final. En el caso de PHP, el compositor funciona perfectamente porque clonará los repos necesarios y cada biblioteca se includeá automáticamente en el autocargador. Cada uno de los proyectos de su país obtendría su propio repository y el núcleo sería un package dependiente. Hay al less una plantilla para administrar drupal con el compositor . Esto puede ser un poco complicado con Drupal dependiendo de cómo escriba el código específico de su región, por lo que esta solución podría no ser ideal. Siempre puede agregar scripts a la installation del compositor para moverlos, si es necesario, como colocar un module específico del país en el subdirectory del module Drupal.

Otra solución que está garantizada para funcionar es el uso de submodules de git. De nuevo, el código común entra en un repository y cada proyecto específico del país obtiene el suyo. El código común se inserta en un directory como un submodule. En este caso, la complejidad se trata de cómo organizas tu código y estructura de directorys.

Sugeriría fusionar todo en un único repository y crear varias sucursales para diferentes lanzamientos. De esta forma, puede generar fácilmente cambios en todas las twigs mediante merge (o rebase, como prefiera). Incluso puede automatizar esto con algún script.