Visual Studio Git解决方案项目疯狂

Question

So i'm trying to figure out how best to structure my git repositories with my .net web application projects and database projects while using git and am really struggling.

We are using feature branching workflow and continuous integration with dev and master main branches currently.

So here's the scenario... say i have 6 projects.(3 web and 3 database)

websiteA (has queries to database1) websiteB (has queries to database2) websiteC (has queries to database1, database2, and database3)

database1 (references database2) database2 (references database1) database3 (references database1 and database2)

all projects are deployable independently although there are many times where they need to deploy together.
(yes i know this is a mess and needs to be cleaned up).

My question is how would you structure the git repos. Here are a few options I have considered.

1. Git repo with solution for each? seems like this would be more modular and less noisy in the repo but more coordination is needed when pushing db and web code.

2. one big git repo with all the projects in them? seems this is a bit easier to be able to work across multiple projects concurrently without having to synchronize so much.

3. git sub modules or git subtree? (worried about these as many of the developers are new to git and these seem to be a little more complicated to me).

4. other options? Any thoughts? Appreciate your help.

Answer 1

I think that a big repository with all the projects is, at least for the moment, the way to go ( monorepositories )

Because : * easier to set up * easier to use, especially like you say, when all your users don't have a lot of git experience

Go with that and gain experience and extract submodules later if you see that's appropriate (and when developers are more experienced using git)

Answer 2

I think having several repos or subtrees makes sense if the dependencies can only change during releases. For example a python module depends on the builtins and other python modules but lives in its own repo because the dependencies only change during releases.

So I think the answer would need knowledge of how tightly coupled these systems are.

Some questions you can think of are:

1. Would change in one DB schema cause code to break in a project that is not directly dependent on it? Or do they interact through APIs and this won't affect anything but the direct dependency?
2. Submodules make sense when the projects use each other like libraries, but want to continuously enhance the features from each other. Is this the situation you are in?