CODEWITHSUNDEEP
gitversion-control
Luka Mis
Luka Mis

Reputation: 573

Nesting git repos

I would like ask the community what would be best way to approach nesting git repos for my example. There are two of us that will work on same project that shares code assets. This project will have a lot of smaller projects inside that all share same assets (are dependent on them). Folder structure will be like this:

main_project
 - assets
 - project_1
 - project_2
 - project_3

Is there a way we can have version history for main_project and assets inside and ignore project folders inside and have separate version control history for each individual project?

If this is not possible what would be best approach for this kind of scenario.

tnx Luka

Upvotes: 4

Views: 2973

Answers (2)

mike.pj
mike.pj

Reputation: 1096

We were doing something similar to this at my job. I don't recommend using this implementation. It's a bit confusing until you get used to it.

main_project
.gitignore
- assets
- project_1
-- .gitignore
- project_2
-- .gitignore

main_project/.gitignore (allow placeholder directories in the main project's tree, but git will ignore contents):

project_1/*
!project_1/.gitignore
project_2/*
!project_2/.gitignore

project_*/.gitignore can be blank, but they must be present if you want placeholders in main_project's tree.

You can then run git init in project_1 and project_2 to create separate nested repositories.

Another approach could be to use symlinks, so:

main_project
- assets
project_1
- assets -> ../main_project/assets/
project_2
- assets -> ../main_project/assets/

Upvotes: 0

Trudbert
Trudbert

Reputation: 3198

You could add the subprojects as submodules which I think would be the official approach. It was a little clunky last time I checked (but I worked) but that was some years ago so maybe give that a try.

Basically what happens would be this: Assets and everything not in a submodule folder would be managed by the main project git. In addition to that a file with a list of submodules would be created and managed by that repository. All the submodules would be managed in their respective own repository (that can be moved around, cloned, pushed and pulled and stuff because its normal git).

Edit:

Did not know about subtrees @gorilly mentions in the comments that might be the simpler solution

Upvotes: 2

Related Questions