Search code examples
gitrepositorygit-submodulesreposubtree

Interrelated Projects in Git Repo

I have multiple git repos and for convenience reasons I want to put them inside another super-repo, but I don't really know how to handle this. Let's say I'm working on a project containing a frontend and an api - each being a seperate repository.

For convenience sake I want to have a repository containing both projects and some additional build- and start-scripts. I mostly come along git submodules. But with submodules being linked to specific commits, my super repo gets changed every time one of my sub-repos changes. Which would be quiet often, as I intend to be developing inside these sub-repos. Git subtree also does not really seem to be what I'm looking for.

I basically just want to have a container saying "this projects consists of these sub-projects that are linked to these remote repos". But I don't want my container project to keep track of the sub-projects.

I came along gitslave, which looks promising for what I want, but windows support and documentation in general, seem to be poor.

So how would I handle a scenario like this?

Solution

  • I think you are confusing the purpose of a project or workspace and the purpose of a repository, here are some thoughts...

    1. Does the Frontend project have a compile-time dependency on the API? Meaning does the API define any convenience layer for the Frontend?

      • If no, then it sounds like you should not be trying to use submodules or git in order to define your project. Instead simply clone both repos into the same folder and use an IDE that has the ability to open an arbitrary folder as a project (see sublime). In this case the project/workspace is different from the git repository.

    2. Do you plan on creating multiple Frontend projects, each using a single API? For example maybe you would have an investing application and a budgeting application that both talked to the same service.

      • If yes, then I would suggest using git submodules. The frontend1_repo and the frontend2_repo would both have the same submodule, the api_repo. The frontend1_repo and the frontend2_repo would then be able to independently track the version of the api_repo that they were compatible with (when/if you eventually make breaking API change). Please consider using semantic versioning. Then use any IDE you want, in this case the git repository is the same as the project/workspace.

      • If no, then I would suggest simply embedding the API repo in the Frontend repo. This reduces project maintenance and avoids any versioning that needs to take place. Then use any IDE you want, in this case the git repository is the same as the project/workspace. Please keep in mind if you maintain a clean folder structure then you can cherry-pick the API directory out into a new repository if you eventually want to create a new Frontend in the future.