3

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?

Jan Petter Jetmundsen
  • 546
  • 6
  • 16

1 Answers1

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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • If you're using TFS 2013 to migrate to Git, then note that submodules are not yet supported and the Visual Studio Tools for Git don't really know how to handle them. It is possible to use submodules from the commandline though. – jessehouwing Dec 31 '13 at 15:31
  • 1
    @jessehouwing Good point. I have included it in the answer for more visibility. – VonC Dec 31 '13 at 15:53
  • I guess that it would be smart to learn command line git from the get go. I am thinking using SourceTree in addition to TFS 2013. I don't know if SourceTree supports sub modules, but I will definitely check this out. Thanks for great input! – Jan Petter Jetmundsen Dec 31 '13 at 20:43
  • @JanPetterJetmundsen You can use any GUI you want (and SourceTree supports submodules since 1.3, Q1 2012: http://blog.sourcetreeapp.com/2012/02/01/using-submodules-and-subrepositories/). But you can *also* install Git in command-line *in addition* of any other git-related tools. It is a good alternative to fall back when said other tools fail. – VonC Dec 31 '13 at 21:12