CODEWITHSUNDEEP
gitworkflow
0_0
0_0

Reputation: 209

Recommended git repository structuring

I have a project which relies on 4 components, each of which does a different task.

Changes done in one module may require (but not necessarily) changes on the other components.
I've maintained a git repository for each individual module.

So, Project
    repo1 -> Component A (PHP)
    repo2 -> Component B (NodeJS)
    repo3 -> Component C (NodeJS)
    repo4 -> Component D (JAVA)

I am now advised to use a single repo for the entire project.
However, I am paranoid, that in the future, if the module increases in size or structure, it would be better to maintain the module in a self repo than the single repo.

I want to achieve the following :

What is the recommended git structure/workflow for this?

Notes :
The entire codebase is still local.
I tried using subtree, and I now have a single project which retains all the commits from other components, I am not sure after using subtree, if, in the future splitting a module to a separate git repo would be possible. (I've heard not good things about sub modules, so did not try that yet).

Upvotes: 0

Views: 110

Answers (1)

Brian Campbell
Brian Campbell

Reputation: 332736

If they are independent projects that can be updated independently, then keep them as separate projects. Don't use submodules, don't mix them into a single module. Just develop them independently.

If there are changes in one component that affect another, use some kind of API versioning to deal with that; make sure that when you make an incompatible change in one, that you update the version number, so that if someone pulls just that and not the other one, they'll know immediately what went wrong.

Beyond that, just treat them as independent projects, and deploy the latest version of each one. There's not much need to complicate it beyond that.

If they are intimately linked, and one can't exist independently from the other, and just about every significant change requires that two of them are updated together, then just develop them in one big repository. If things are that tightly linked, it doesn't make sense to split it up. Use your deploy scripts to deploy from the one big repository to the different servers.

Whichever one you choose, don't worry about it too much. One of the nice things about Git is that it's fairly easy to merge or split repositories later once you realize that you did it wrong. If you try the split approach and it winds up being too confusing or cumbersome, do a subtree merge and now you have a single unified repository. If you try the unified approach and it gets too big? Run git filter-branch over it to separate out each of the subdirectories for the subcomponents, and now you have several independent repositories (do keep the original around in this case, so you actually have the full unified history, in case that becomes relevant in the future).

Upvotes: 1

Related Questions