Team Foundation Version Control Verses Git in Visual Studio Team Services
In this Ask the Admin, I will look at centralized versus distributed version control in Visual Studio Team Services (VSTS). I will also look at how to choose for your Infrastructure-as-Code project.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
VSTS is a source code management solution for developers that is based on an Azure-hosted version of Microsoft’s Team Foundation Server. It includes Git and Team Foundation Version Control (TFVC), integration with Visual Studio 2017, team collaboration tools, and features that enable continuous integration.
For more information on VSTS, see What Is Visual Studio Team Services? on the Petri IT Knowledgebase.
While VSTS offers Git as the default for version control, VSTS users can also choose TFVC, which is Microsoft’s own version control solution.
Git is an opensource distributed version control solution that allows developers to download code from a server, make changes to the code locally, and perform operations, such as comparing and viewing history. This is done without needing to maintain a connection to a server.
Unlike most version control solutions, Git’s lightweight path-independent branching allows developers to quickly create new branches, usually one for each new feature they are working on so that they can work on code without affecting the main branch. Once a developer has completed the code in a branch, it can be merged, published, or deleted as needed.
Team Foundation Version Control
Microsoft’s TFVC is a centralized version control system where members usually have one version of a file on their local PCs. TFVC branches are path-based and created on the server.
Two different types of workspaces are used to facilitate making changes. Server workspaces are used to check out files before a developer starts making changes and requires a connection to the server. Local workspaces allow developers to make a copy of the latest version of the code on the server, make changes locally on their PC, work offline, check on files that have changed, and resolve any conflicts that occur.
Git Versus TFVC
Git is the default version control solution in VSTS because it is fast, lightweight, and flexible. It is the recommended version control solution in most cases, especially those just starting out with Infrastructure-as-Code.
But TFVC’s path-based branching is useful for reducing risk among feature teams and releases where functionality being integrated by different teams is co-dependent. Unlike TFVC, files cannot be locked in Git and granular permissions can apply only to a branch or repository. Additionally, TFVC scales better than Git because server workspaces ensure that only one copy of a file is present on developers’ PCs. Finally, code in TFVC can only exist on one server, whereas Git allows repositories and commits to be pushed to multiple sources.
In this article, I explained the differences between Git and TFVC version control solutions.