Setting up a Git repository for a .NET solution

Question

I have a solution with 15 C# projects and I'm trying to set up an efficient git repository for them. Should I create a repository on that level or for each project under the solution?

WebServices/
|- WebServices.sln
|- WebService1/
 `- WebService1.csproj
|- WebService2/
 `- WebService2.csproj

The solution has a project reference to ../framework/framework.csproj which is a seperate repository and all the other projects have a reference to. The projects under the solution are not linked in any way, but they all use the framework.

I would like any changes to the framework would be passed to the projects.

Do you have any guide for me how to achieve that in the best possible way?

Answer 1

There is no one answer to how to set up your repository. It depend on your specific needs.

Some questions you should ask yourself include:

1. Are all projects going to be released and versioned separately?
2. Are the projects really independent of each other?
3. How is your development team structured? Do individual developers stick to a single project?
4. Is your framework project stable?
5. Does your build process build each project separately?

Assuming that the answers to all of the above is "yes", then I would set it up like so:

• Continue maintaining the framework code in its own repository, and publish it to an internal server using NuGet (as suggested in ssube's comment).
• Create a separate repository for each project, each with their own solution file.

If you can say "yes" to all except #5 (and possibly #1), above, then I would add one more repository that consists of submodules of each of the individual projects and a global solution file that your build server can use. If you add a new project, you have to remember to also update this repository!

If you have to say "no" to #2, then just build a single repository.

If you have to say "no" to #3, then you'll have to make a judgement call, between separation of the code and developers' need to switch between repos. You could create a separate repository including submodules, but if all your developers wind up using that repo, you are really only introducing new maintenance with little gain.

If your framework is not stable (#4), then you may want to include that as a submodule in any of these cases. I recommend that once it becomes stable, then you look into removing the submodule and switching to NuGet at that time.

Answer 2

What i have done for such a situation was the following. Note that in my case there were 2-3 developers.

So i have 3 things in this:

1. The empty project structure that i would like to replicate [OPTIONAL]
2. The common library projects
3. The actual end projects that use common library projects

1) I just create my scaffold development directory structure and i am putting a .gitkeep file in each and everyone of them in order for git to include it. In this way when i want to setup myself in a new pc i just clone this and i have my empty development "universe" structure. Then i populate (git clone) with the projects i need.

2) The common libraries project is just a normal repo.

3) My end projects reference the common library projects. There are prons and cons about it and depends on your situation, but i what i gain is that i can change the common libraries either directly from the common library project, or from the end project which references it. In both ways i get the changes in git and commit normally and separately.

In your case i would have my empty structure and then do 2 separate clones. The framework project in the correct place and then the entire webservices repo.

Its up to you if you want to have a separate repo for each web service or one for all. It depends on your person count and work flow.

Also do not forget a proper .gitignore Here: LINK