Reputation: 1706
I am working on building a Django website in which the core is stored in one repository, and the individual customer implementations/deployments are in another. The core is the minimal website, and needs to be "runnable" as is for testing purposes. Meaning the core will look something like:
Core:
- mainapp
-settings.py
-urls.py
-__init__.py
-wsgi.py
- otherCoreApp
-views.py
-...etc.
- manage.py
The implementations would initially be a clone of the core, and then have the remotes setup to push/fetch to a separate repo. The implementations remotes would look something like:
core https://github.com/core.git (fetch)
core no-push (push)
origin https://github.com/customer1.git (fetch)
origin https://github.com/customer1.git (push)
And the file structure:
Customer1:
- mainapp
-settings.py # Changed from core
-urls.py
-__init__.py
-wsgi.py
- otherCoreApp
-views.py
-...etc.
- pluginApp1
- pluginApp2
- deploymentConfig
- manage.py
This would then allow updating the core into the implementation by running git pull core master
. The core files will not change much in the implementations, as the main way of expansion will be via plugins.
If development of any core pieces is kept to the core repository, is this a viable strategy?
Upvotes: 1
Views: 70
Reputation: 879
Having extra files in the customer repos implies there will be commits in those repos which are not in core
. Since the customer repos edit a file saved in core
, I see two options for how you would pull:
core/master
onto a fresh branch with the :
syntax, rebase master onto it and resolve the merge conflicts from there.Not necessarily downsides, just something to think about.
Aside from that, this is an interesting application of multiple remote repositories, which most people forget git has.
Upvotes: 1