Help creating submodules in my Bare repository.

First of all, I know you cant do Submodules in a Bare Repository, but I’ll an Scheme of my project to give some context.


I need to create a remote repository with a cloned one in Local. Inside it, I want to create “Global” folders with TAGs for each time there is a change inside. The next sublevel might be a main folder and N part folders, all with .csv in it and with separated TAGs here too in each folder.

I’ve been trying things for days, but not getting far. 

Could anyone help me out to solve this mess? 


Hello, thanks for joining us!

If I’m understanding what you’re describing, this structure that you’re describing looks like one of the recommended best practices for Subversion, a different source control software than Git. The reason this is a best practice for Subversion is because it has a completely different approach to tagging and branching than Git does. With Git, you don’t need to, and shouldn’t, store tags or branches as physical paths in the repository.

If I’m misunderstanding, can you share some more details as to what in your diagram is intended to be file structure and what is intended to be repository references?

Hi! Thanks for the reply and sorry for the delay.

Well, I know subversion could be a way to get this, but I need to use Git no matter what…

I ended up doing a different schema,


Where I have N Repositories (1 core, N Assets) remotely and cloned in local. So I edit the ones in local and then push it to origin individually.

But now I need to have some kind of Log or something where I keep the global version of the group of repositories all together.

Is there any better solution? 

Thanks in advance.

I might be a bit late to the party, but… I think here you were discussing two different questions.

I need to have some kind of Log or something where I keep the global version of the group of repositories all together.

This is indeed doable by git submodules, which are just a special kind of object pointing to a repository URL and commit - like symbolic links in a filesystem. You can have a “dispatcher” repository with lots of such links defined; you can have branches and versions of this repo pointing to different sets and revisions of components of your ecosystem (e.g. to track what constitutes a product release bundle). And it being a git repository storing lots of such references, it can be represented by a bare repo too.

The other question is checking out all your codebase dispersed into many git repos. This, it seems, requires that you git clone this dispatcher as a full repo with a workspace - and in that workspace do the git pull, maybe git submodule update and other magic, to get workspaces with those component sources as well.