I'm trying to set up a repository system which allows projects to share a "framework" remote, so that bugfixes to the framework can be pulled into the projects.
My approach for this is to set up a bare repository at //NAS/projects/base
, clone it to a bare repository at //NAS/projects/projectX
, and rename projectX's remote from origin
to framework
to avoid confusion. The intention is that then each developer can clone //NAS/projects/projectX
and push their changes back to that repository, and the framework maintainer can clone //NAS/projects/base
and push their changes back to that repository. Then projectX
can pull from base - and here my approach falls down because I can't pull into a bare repository.
There are existing questions about setups which seem superficially similar but on inspection appear to address only the case where the second bare repository is a mirror of the first. That isn't the case here: I want to be able to create a projectY
which also uses the framework and gets its changes but without any code specific to projectX
or projectY
ending up in base
.
How does git support this kind of structure? Does someone need to add base
as a remote to their local repository, pull from it, and then push into projectX
? I can fetch from base
into projectX
: is there some command I can then do to rebase its master to the HEAD of base
's master? Or am I going about this in completely the wrong way?