Un proyecto, ¿Múltiples clientes con git?

Question

Soy nuevo en GIT y todavía no sé cuánto se ajustará a mis necesidades, pero se ve impresionante.

Tengo una sola aplicación web que utilizo para diferentes clientes (django + javascript)

Planeo usar GIT para manejar estas versiones de clientes diferentes como sucursales. Cada cliente puede tener archivos, carpetas y configuraciones personalizadas, versiones mejoradas ... pero deben compartir el mismo 'núcleo'. Somos un equipo pequeño y suscribimos una cuenta de github.

¿Es la rama la buena manera de manejar este caso?

Acerca del archivo de configuración, ¿cómo procedería? ¿Desearía ignorar el archivo de configuración específico del cliente y agregar un archivo settings.xml.sample, por ejemplo, es el repositorio?

Además, ¿hay alguna forma de evitar que algunos archivos se fusionen en master? (pero comprometido con la sucursal del cliente). Por ejemplo, a id le gusta guardar algunos datos del cliente en la sucursal del cliente, pero evitar que se comprometan a master.

¿El archivo .gitignore es específico de la rama? SÍ

EDITAR Después de leer todas sus respuestas (¡gracias!) Decidí refactorizar primero la estructura de mi proyecto django para aislar el núcleo y mis diferentes aplicaciones en una subcarpeta de aplicaciones. ¡Hacer esto hace un proyecto más limpio, y ajustar el archivo .gitignore hace que sea fácil usar ramas git para administrar los diferentes clientes y configuraciones!

Ju.

Answer 1

Además de la respuesta de cpharmston, parece que necesita refactorizar para separar lo que es realmente personalizado para cada cliente y lo que no lo es. Luego, puede considerar agregar repositorios adicionales para rastrear las personalizaciones para cada cliente (repositorios completamente nuevos, no sucursales). Entonces su despliegue puede tirar de su "núcleo" de su repositorio principal y las cosas específicas del cliente de ese repositorio.

Answer 2

No usaría ramas para lograr lo que está tratando de hacer.

En el control de fuente, las ramas están destinadas a ser utilizadas para cosas que deben fusionarse nuevamente en el tronco. Por ejemplo, Alex Gaynor pasó su verano de código trabajando en una rama de Django que permite el soporte para múltiples bases de datos , con el objetivo de eventualmente fusionarlo nuevamente en el tronco de Django.

Pagar (o clones , en el caso de Git) podría adaptarse mejor a lo que está intentando que hacer. Debería crear un repositorio que contenga todos los archivos base del proyecto (y archivos .sample, si lo desea), y clonar el repositorio en todas las ubicaciones en las que desea implementar el código. Luego, cree manualmente los archivos de configuración y personalización en cada implementación (tenga cuidado de no agregarlos al repositorio). Cada vez que actualice el código en el repositorio, ejecute un pull en cada implementación para actualizar el código. ¡Viola!

Answer 3

Matthew Talbert es correcto, realmente necesita separar las cosas personalizadas de las no personalizadas. Si puede refactorizar todo el código central que se incluirá en un directorio, sus clientes pueden usarlo como un submódulo git de solo lectura. El beneficio adicional es que los bloquea en una versión explícita del código central. Esto significa que tendrían que actualizarse conscientemente a una nueva revisión, que es lo que desea para el código de producción.

Answer 4

Otras respuestas son correctas de que estará en la mejor forma para el mantenimiento en la medida en que separe su código central del código personalizado por cliente. Sin embargo, me separaré de la multitud y diré que si no puede hacerlo (por ejemplo, porque necesita agregar funcionalidad adicional al código central para un determinado cliente), las ramas de DVCS funcionarían bien para lo que desea hacer. . Aunque probablemente recomendaría ramas por directorio en lugar de ramas en el repositorio para este propósito (git también puede hacer ramas por directorio, no es más que un repositorio clonado que diverge).

Uso hg, no git, pero todos mis proyectos de Django se clonan desde la misma base "plantilla de proyecto". repositorio que tiene scripts de utilidad, un conjunto común básico de INSTALLED_APPS, etc. Esto significa que cuando realizo cambios en esa plantilla de proyecto, puedo combinar fácilmente esas actualizaciones comunes en proyectos existentes. Esto no es exactamente lo que está planeando, pero es similar. De vez en cuando tendrá que lidiar con conflictos de fusión, si modifica la misma área de código en el núcleo que ya ha personalizado para un cliente específico.

Answer 5

Después de leer todas sus respuestas (¡gracias!) decidí primero refactorizar la estructura de mi proyecto django para aislar el núcleo y mis diferentes aplicaciones en una subcarpeta de aplicaciones. ¡Hacer esto hace un proyecto más limpio, y ajustar el .gitignore en el archivo de diferentes ramas hace que sea fácil usar ramas git para administrar los diferentes clientes y configuraciones!