Tome una aplicación laravel creada, una forma de crear algo así como 2 aplicaciones que comparten un núcleo.

He creado una aplicación de caridad laravel 5.3

ahora el cliente me dice:

Quiero volver a tener la misma aplicación, pero solo para ciertas cosas, por ejemplo, la misma aplicación, pero solo para donaciones de caridad para la naturaleza. Así que nuevo logo, diferentes correos electrónicos, etc.

¿Cuál es una buena manera de hacer posible compartir actualizaciones en las dos aplicaciones sin tener que volver a hacer todas las confirmaciones y fusionar las confirmaciones manualmente en cada subproyecto?

Pensé que tal vez de alguna manera tendrías un proyecto central, y un repository de git separado que solo contiene los files que deseas sobreescribir en dicha aplicación … no estoy seguro de qué herramientas usar, etc. o si hay algo más inteligente.

EDITAR Pensé en crear desde la aplicación A un proveedor de services que incluye todo lo de la aplicación A, hacer que esté disponible a través del package de compositor. Ahora, la aplicación CLONE utilizará este package de proveedor / compositor de services. Cuando realizo una actualización al proveedor de services de la aplicación AI, solo ejecuto una actualización de compositor en mi aplicación clonada. Problema: ¿y si la actualización necesita migraciones de bases de datos?

Una buena forma de hacerlo sería configurar dos aplicaciones de Laravel y luego crear un package de Composer que contenga todos los componentes principales.

Puede vincular fácilmente packages en Composer alojados en repositorys privados, evitando por completo Packagist.

Configurarlo en el file composer.json es bastante fácil. Los files del compositor de aplicaciones seguirían este tipo de patrón:

 { "type": "project", "repositories": [ { "type": "git", "url": "git@github.com:your/package.git" } ], "require": { "your/package": "dev-master", ... } } 

Mientras que el package común seguiría esto:

 { "name": "your/package", "autoload": { "psr-4": { "YourPackage\\": "src/" } } } 

Luego solo ingrese las classs / ayudantes comunes en el repository your/package.git , y puede acceder fácilmente a ellas en ambos.

Puede usar tanto git alternates como funciones de clonación superficial para compartir objects entre repositorys. Esto es algo que github hace para ahorrar en el espacio de almacenamiento cuando los usuarios bifurcan un repository.

Básicamente, la function alternativa le da a git un nombre de ruta para encontrar objects en. Mientras que el clon superficial (se puede hacer localmente) le da una cierta cantidad del historial de compromiso que usted especifica con la opción de profundidad.

Convenientemente, git clone puede configurar la ruta alternativa para usted. El command que ejecutará debería verse más o less así:

git clone -l -s [ruta al repository original]

Tenga en count que no incluí la opción de profundidad en el command.

Aquí está la documentation para los suplentes: https://git-scm.com/docs/gitrepository-layout Y aquí está la documentation para clonar: https://git-scm.com/docs/git-clone

Convierta el sitio en multicliente en este caso. Esto permite que se sirva contenido completamente independiente mientras se opera a través de la misma stack, desde los datos hasta la capa de presentación. Vea este package:

https://github.com/HipsterJazzbo/Landlord

Esto también le ahorrará el dolor de cabeza de administrar migraciones independientes ya que ambos sitios usarán la misma estructura de db.