¿Cómo usar git para sitios subsidiarios?

Espero que este sea el lugar correcto para preguntar; dame una bofetada si no.

Tenemos un website, actualmente mantenido con git. Estamos planeando revender el website, mantener el código y demás en nuestro server, cambiarle la marca y realizar ciertas modificaciones para los clientes. No es un simple "mostrar un CSS diferente", cada cliente tendrá un código real y modificaciones lógicas basadas en nuestro código central.

¿Cuál es la mejor manera de gestionar esto en git? He observado remotos, submodules, mantenimiento de repositorys diferentes, pero ninguno parece hacer clic.

Mi plan era, tenemos nuestro repository de código central, y cada cliente (incluido nuestro propio sitio) obtiene su propio repository (o submodule, o lo que no). Podemos modificar su código específico y, si necesitamos insert algo en el código central, también debería ser fácil enviarlo a los sitios del cliente.

Creo que mi problema aquí es express lo que quiero; si pudiera hacer eso, entonces git probablemente respondería con "esto es lo que necesitas".

¿Algunas ideas?

No estoy seguro de por qué una simple twig no funcionaría en su caso. Si tiene problemas de control de acceso, siempre puede insert estas twigs en repositorys diferentes (opcionalmente en diferentes máquinas), pero en function de lo que describa, no veo ningún punto en los submodules ni nada de lujo.

Luego, puede simplemente fusionar su twig de "código principal" en la twig de cada cliente cuando llegue a un hito.

En Git no hay nada especial acerca de la twig master más allá de que es donde comienzas. La mayoría de las personas usa el master como el "tronco" para todas sus twigs, lo que espero que haga con su código base.

La forma más sencilla de manejar su situación es con twigs master específicas del cliente (por ejemplo, foo-company/master , bar-company/master ). Usted no tiene que usar una "carpeta" de sucursales por compañía, pero puede ayudar a mantener algo separado de la compañía del desarrollador central. Puede optar por usar controles remotos por separado en su lugar, pero no creo que la complejidad adicional le gane nada a less que los clientes necesiten acceso solo a su versión del código .

Como el trabajo se realiza en el master y los clientes quieren nuevas funciones, tiene algunas opciones:

  1. Combine el master en las twigs de su company/master periódicamente y resuelva los conflictos a medida que ocurren. Dependiendo del scope de la desviación del master , esto puede ser un desafío. git rerere puede ayudar.
  2. Si siempre piensa en la personalización de cada cliente en términos de "cambios desde el master ", puede considerar el uso de rebase para mantenerse actualizado. Si los cambios generalmente están bien contenidos, esto puede facilitar la resolución de conflictos. O puede terminar golpeando los mismos conflictos una y otra vez, si los cambios sucesivos modifican los anteriores.
  3. Si los clientes solo desean nuevas funciones específicas de master , puede usar cherry-pick para extraer las confirmaciones de funciones específicas en las sucursales de la empresa.