Git和TFS版本控制团队合作

Question

we are a medium company with about 15 C# developers

We would like to dismiss sourcesafe (five years talking about it!!!) and go to use Git and TFS

Git because is probably the past, the present and future in version control and TFS because we would like to have all centralized and VS integration/functionalities

In particular we want to avoid two or more people working on the same file at the same time

We have 3 big products

• erp
• cash point software
• web products catalogue (all other web project)

So there are 3 teams working on the 3 projects/areas

We have common classes used by all teams and specific classes used by each team

For Example

Proj1 uses:

• Solution Project (windows form)
• Class1 Common
• Class2 Common
• Class1 Erp
• Class2 Erp

Proj2 uses:

• Solution Project (windows form)
• Class1 Common
• Class3 Common
• Class4 Common
• Class1 Cash Point
• Class2 Cash Point

Proj3 uses:

• Web Project
• Class1 Common
• Class2 Common
• Class3 Common
• Class1 Web
• Class2 Web

We would like to create a repository for each class and then use them in main project solution but i've read it's not possibile with Visual Studio and TFS (git subdirectories).

Is it right?

how can we have this result in another way?

What we would like to avoid is to create a unique repository and force developers to download all classes and solutions

Answer 1

Your solution setup sounds very Source Safe'ish (which makes sense, since that's what you're using), but the old strategy won't carry forward into Git nor TFVC easily. The VSS Pin feature is missing from both systems, so you can't use the same file in multiple folders ¹⁾ .

Let's take your questions:

We would like to dismiss sourcesafe (five years talking about it!!!) and go to use Git and TFS

Great! That sounds like a really good idea. While you're at it, I'd really suggest you look into Visual Studio Team Services vsts over TFS. It sounds like your organisation isn't very good at staying current and making the step to VSTS will help you with that. Microsoft will automatically keep you current every 3 weeks.

If you need to stay on-premise, make sure people are on board with yearly major upgrades and about quarterly service pack installations.

In particular, we want to avoid two or more people working on the same file at the same time

As to locking files, that's a thing of the past. Given the distributed nature of Git, it's not meant to lock anything. It uses very advanced merging techniques to try and make it as easy as possible to merge your changes, no matter what mess you're making. Git was originally developed to support the Linux Kernel sources and manage asynchronous changes from people all around the world. Central locking would be a nightmare in that scenario.

In TFVC the concept of locking still exists, but only if you're using the 2010 style Server Workspaces. The Local workspaces introduced in 2012 (and default for most projects) have done away with locking files as well. TFVC does have more features to help you in this respect (over Git), the Incoming Changes code lens, for example, will warn you when others have checked in code right above every method to prevent you from accidentally editing them without syncing sources first. Locking files only works when: all developers are using server workspaces and when exclusive checkout has been explicitly turned on (default is off since 2005).

So while TFVC supports exclusive checkout, all the defaults try to turn you away from this workflow. This should be saying something.

We would like to create a repository for each class and then use them in main project solution but I've read it's not possible with Visual Studio and TFS (git subdirectories).

It's probably best to extract your shared classes to a separate project and to then either put that separate project in a Git Submodule, or to package that separate project into a NuGet package and reference these shared classes in your other projects that way.

Visual Studio 2017 has "support" for submodules. It can load them and shows them in the changes window, but the UI is not very intuitive and needs a bit of work to make it easy to use. You're psobably going to have to rely on using the git commandline a lot when taking the submodules route. The VSTS/TFS Build agents (not the XAML agents) also support submodules.

TFS 2018 and Visual Studio Team Services offer a built-in NuGet repository feature (package management) which you can leverage to then share and manage these shared classes. I'd personally recommend that route. Create a separarte repository for shared code and configure a CI build to automatically create a NuGet package with the latest changes. You can then reference this NuGet package from the dependent projects.

Regardless of your target solution, you're likely going to have to refactor your solution structure a bit. Submodules can only be loaded into subdirectories.

What we would like to avoid is to create a unique repository and force developers to download all classes and solutions

I wonder why, but if you want to break out into separate repositories, then either submodules or separate Git repositories + NuGet packages will solve this for you. The NuGet solution will work with TFVC as well.

Also remember that with Git you always create a full local copy, including all history of your linked repositories.

Answer 2

thanks for your answer

About migration to Git and TFS as you now people hardly change from what they know to unknown. i'm working on it....

Another problem is we have to stop working for some days (how many? who know?) during migration with danger to lose data or parts of code

But i'm confidet we will do it

About locking files i think it's difficult to know if it is a good or a bad thing. i believe it's depend on situation

In our scenario (small/medium company), where developer works on a specific project without interaction with other, it's valid

In a scenario of changes from people all around the world, as you wrote, it's not valid

I also tried visual studio's merge and i found it very uneasy and we change 1 code line just for a try! I don't know how it can be if you have to merge more parts of code. Much better is Git's merge

How many times developer will lost on merging files or fix code?

About VS which support more than one repository i readed it's not possible just one month ago

Can you send me something about it please? You wrote we will have to use submodules and a lot of Git commandline. Don't you think it's very uncomfortable compared to a sourcesafe's management? Or it would suffice that VS let's open repositories like references

We also thought about nuget packages We was ready to start with these solution but some developers complain they will not be able to change code runtime during debug (it's so diffucult to make agree many people....)

Another problem is you have to deploy every time your nuget packages and their dependeces. it's more complex than have references as projects

I will treasure about your answers trying to change our mentality