从TFS迁移到GIT，将共享项目迁移到nuget

Question

I am working in a software team that consists of 4-5 developers working in a single TFS project. We are considering moving the entire codebase to GIT. The codebase consists of about 50 visual studio (2013) solutions divided into about 300 projects. The preferred procedure of referencing another assembly in a project has been to add the project to the solution and so on. I guess this is considered a bit messy, but it has its perks:

1: Given that the source code is updated to latest, the projects will always be updated with the latest when built.

2: When a release branch is created, the complete picture of the sources state is stored, and it is easily possible to reproduce the release if (when) needed.

When considering migrating to GIT, the easiest way would be to simply move all the solutions and projects, pretty much as is to a single GIT repo. This leads me to my first question.

Will a collection of 50 or so solutions divided into 300 projects in a single GIT repo be hard to work with? I am afraid to loose overview of the changes performed by each developer on a daily basis.

Another approach, and I think this is the correct way, is to step away from the shared projects regime and divide the codebase into logically divided parts with their own GIT repos. (I would guess this would leave us with about 10-20 repos). To solve the referenced projects in this matter, we are considering using a local nuget-server.

This leads me to my second (and last) question. Take a look at the perks mentioned above. Can these features still be maintained? Can we “auto-update” the nuget references in the working branch, but freeze them to a specific version on a release branch?

Answer 1

I am afraid to loose overview of the changes performed by each developer on a daily basis.

No, you won't loose that overview, and can easily measure the contribution of one collaborator (like, for instance, in this answer )

Can these features still be maintained?

Yes: those 10-20 projects would be reunited within one parent repo, as submodules .
And you can easily configure a submodule to follow a branch , like its master branch.
See more on that config at " Git submodules: Specify a branch/tag ", and git submodule .

• auto-update:

   git submodule update --remote --init --recursive 

• freeze:

   cd /parent/repo git add . git commit -m "Freeze all submodules SHA1" 

As mentioned by jessehouwing in the comments, Visual Studio 2013 and its native Git support doesn't include yet submodules. It is highly requested though .
The Git command-line remains available for those update/freeze steps using submodules.