How should I structure my Git repositories with my .NET Solution?
I have a .NET solution that has, let’s say, 10 projects within it.
There are a couple ways of thinking:
- Use a Git repository per project, then use a repository for the solution and submodules. So, each
.csprojfile and dependent file gets its own repository.
- Use a single Git repository for the entire solution. Everything the
.slnfile depends upon.
Looking at option #1, I think would be tough as if you are working on a feature branch, you have to create a feature branch for every referenced submodule. It creates a lot of overhead.
Option #2 seems easier to deal with branching, however, with a large number of developers on a project, you may run into quite a bit of merge conflicts, especially when dealing with the
How do other .NET developers manager their Git repositories with their various solutions.
2 Solutions collect form web for “How should I structure my Git repositories with my .NET Solution?”
The git repository should contain everything needed. That is, cloning a respository should bring down everything needed to work with it.
That said, if the projects are self-contained enough to stand on their own; give them a repository of their own. They can then be brought into the solution as either a submodule (if code is needed while working on the solution) or as a compiled dll (if just the functionality is needed).
We have all our stuff in a single repository that is set up like this
Main folder --> All solution files here -Sub Folder --> All executable projects -Sub Folder --> All library projects -Sub Folder --> All 3rd party DLLs
So if someone is changing a library project, every solution that references it is pointing to the same place. And everything is together and organized, I suppose it causes a little extra overhead since you are always pulling down code you probably will never utilize, but I tend to like this approach.