Take a created laravel app, a way to create someth

问题:

I have created a laravel 5.3 charity app

now the client tells me:

I want to have the same app again, but only for certain things, say, the same app but only for charity donations for nature. So new logo, different emails etc

what is a good way, to make it possible to share updates across the two apps without having to redo all commits and manually merge commits in each sub project?

I thought maybe some way where you have a core project, and separate git repo that only contains the files you want to overwrite in the said application... not exactly sure what tools to use etc or if there is something smarter.

EDIT I thought about creating from app A a service provider that includes everything of app A, make it available via composer package. Now app CLONE will use this service provider / composer package. When I make an update to the service provider of app A I just run a composer update in my cloned app. Problem: what if the update needs database migrations?

回答1:

A good way to do this would be to set up two Laravel apps and then build a Composer package that contains all of the core components.

You can easily link to packages in Composer that are hosted in private repositories, bypassing Packagist entirely.

Setting it up in the composer.json file is quite easy. The app composer files would follow this sort of pattern:

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

While the common package would follow this:

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

Then just commit any common classes/helpers into the your/package.git repository, and you can easily access them in both.

回答2:

You can use both git alternates and shallow clone features to share objects among repos. This is something github does to save up on storage space when users fork a repo.

Basically the alternates feature gives git a pathname to find objects at. While the shallow clone (can be done locally) gives you a certain amount of the commit history that you specify with the depth option.

Conveniently, git clone can set up the alternates path for you. The command you'll run should look something like this:

git clone -l -s [path to orginal repo]

Note that I did not include the depth option in the command.

Here is the documentation for alternates: https://git-scm.com/docs/gitrepository-layout And here is the documentation for clone: https://git-scm.com/docs/git-clone

回答3:

Convert the site to multi-tenancy in this case. This allows for completely independent content to be served while operating through the same stack, from the data to the presentation layer. See this package:

https://github.com/HipsterJazzbo/Landlord

This will also save you the headache of managing independent migrations as both sites will use the same db structure.