0

We've got a unique setup we're trying to accommodate for a set of projects on a common platform. Basically, there's an environment that's common to all projects that needs to have its own repo. Inside that is a directory with all the core code for the platform. This also needs its own repo. Inside a subdirectory within the core repo, there are a handful of sibling directories corresponding to themes that a project might utilize. Each of these needs its own repo. Then, for a particular project, there's a subdirectory inside of the chosen theme that contains configurations and other custom code for the particular project. And this is the repo that we will work on most. Everything upstream from there are dependencies. It looks something like this:

Environment------------------------------------------------------- |--(some code) |--Core----------------------------------------------------------- | |--(some code and directories) | |--Themes directory | | |--Theme1--------------------------------------------------- | | |--Theme2 (chosen)------------------------------------------ | | | |--(some code and directories) | | | |--Project----------------------------------------------- | | | | |--(This is the code that changes for every project) | | | | ------------------------------------------------------ | | | --------------------------------------------------------- | | ------------------------------------------------------------ | --------------------------------------------------------------- ------------------------------------------------------------------ 

Is there a way to set this up so that a developer can pull down the project repo, and it will pull all the dependency repositories with it? We've been looking into submodules and subtrees, but we keep running into snags (and I admit that we may just be missing something here). I would greatly appreciate any pointers or guidance anybody has.

Thanks!

2 Answers 2

2

As you've discovered, using separate repos for all of this is a mess. I would instead suggest using branches. Start with the most generic part (the Environment), then make a branch for the next level down (the Core), then a branch for the next level down (Themes) and finally a branch per Project.

A - B - C [Env] \ D - E - F [Core] \ G - H - I [Themes] \ \ \ L - M [Project2] \ J - K [Project1] 

Each piece can be updated by merging with its upstream branch. Developers can clone with --single-branch to just get the pieces they need.

Sign up to request clarification or add additional context in comments.

Comments

0

One option would be to just make a separate repository for each module (one for environment, core, themes, etc) but include a package.json-esque file that lists out that repo's dependencies.

Then, you can either use an existing dependency-management tool (like bower, for example) or write your own script that will simply git clone each dependency in package.json and insert it into your current repo as a fake submodule.

Lastly, you can use a git alias to make it easy for your developers to clone a repository, and then do a git install (which is akin to a bower install) to grab all of its upstream dependencies.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.