16

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?

Gaui
  • 8,723
  • 16
  • 64
  • 91

4 Answers4

15

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.

Steve Czetty
  • 6,147
  • 9
  • 39
  • 48
  • 1. Yes, all projects are going to be released and versioned seperately. 2. Yes, all projects are really independent of each other. Except the framework, it's included in all projects. 3. 4 developers working on same projects. 4. No, the framework project is not stable. 5. It should build each project seperately, yes. And the build server watches certain git repositories and branches. That's why we can't have a single repo for everything. – Gaui May 08 '14 at 21:32
  • I agree with everything in this post. Now, how do I get my co-workers, who are new to Git, to not destroy the dev branch with detached HEAD craziness due to them not knowing how to deal with submodules. Having terminal-phobic Git noobs use Git submodules is my worst nightmare. Even subtrees aren't much better. I'm tearing my hair out over here, sorry about the rant. – Gagege Mar 13 '16 at 20:45
1

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

Community
  • 1
  • 1
e4rthdog
  • 5,103
  • 4
  • 40
  • 89
1

If

  • you really want to have all projects in the same solution
  • the common project "Framework" is in active development (and some modifications for one project could break others...)

i think you must have each WebService as a git project with his own copy of Framework project as submodule:

WebServices/
|- WebServices.sln
|- WebService1/
 `|-.git  
  |-WebService1.csproj
  |-Framework (as submodule)
|- WebService2/
 `|-.git  
  |-WebService2.csproj\
  |-Framework (as submodule)

This way each WebService will use the Framework version that is compatible with.

(of course you must be aware of git submodule workings... you could read for example this, specially the section "Issues with Submodules"!)

Important: with this configuration each deployed webservice must reference the Framework library with the actual version it is using!

DaniCE
  • 2,412
  • 1
  • 19
  • 27
0

Depending on "how independent" development going to be for each of your projects you might consider two option.

  • in case you are mostly working on entire solution - create one repo for entire solution

  • in case some projects are really independent , create separate repos for those projects and create solution file for each project aside project file, then use git submodules to reference those repos in the repo of the main solution, that make use of those projects.

Git Submodules Tips

vittore
  • 17,449
  • 6
  • 44
  • 82
  • 6
    If your libraries are actually libraries (semi-stable, shared), you're much better off using some kind of dependency management system that handles such things (NuGet, Maven, etc). Submodules work best when you want to share source and get ugly when you're sharing build artifacts. – ssube May 06 '14 at 16:48
  • Agree, in our company we are discussing creating of our internal NuGet server for quite some time, exactly for this reason. – vittore May 06 '14 at 16:53