What are the big differences between TFVC (TFS Version Control) and Git for source control when u...
Categories:
TFVC vs. Git: Choosing Your Source Control in Visual Studio 2013

Explore the fundamental differences between TFVC (Team Foundation Version Control) and Git for source control within Visual Studio 2013, helping you decide which system best fits your development workflow.
When working with Visual Studio 2013, developers had two primary choices for source control: Team Foundation Version Control (TFVC) and Git. While both serve the purpose of managing code changes, their underlying architectures, workflows, and capabilities differ significantly. Understanding these distinctions is crucial for selecting the right system for your project, team size, and development methodology.
Centralized vs. Distributed Architecture
The most fundamental difference between TFVC and Git lies in their architectural models. TFVC is a centralized version control system (CVCS), while Git is a distributed version control system (DVCS). This architectural choice impacts nearly every aspect of how developers interact with their code.
In TFVC, there is a single, authoritative server that stores all versions of the code. Developers check out files, make changes, and then check them back into the central server. All history and metadata reside on this server. This model can simplify administration and provide a clear 'single source of truth' for the codebase.
flowchart TD A[Developer 1] --> B(Central TFVC Server) C[Developer 2] --> B D[Developer 3] --> B B -- Pull/Push --> E[Repository] subgraph TFVC Workflow A -- Check Out --> B B -- Get Latest --> A A -- Check In --> B end
Centralized TFVC Architecture
Git, on the other hand, provides every developer with a complete copy of the entire repository, including its full history. When a developer clones a Git repository, they get a local copy of all branches and commits. This allows developers to work offline, commit changes locally, and perform many version control operations without needing to communicate with a central server. Changes are then pushed to and pulled from a shared remote repository (like Azure DevOps Repos or GitHub) when ready to collaborate.
flowchart TD A[Developer 1 Local Repo] <--> B(Remote Git Repo) C[Developer 2 Local Repo] <--> B D[Developer 3 Local Repo] <--> B subgraph Git Workflow A -- Commit Locally --> A A -- Push --> B B -- Pull --> C end
Distributed Git Architecture
Branching and Merging Strategies
The architectural differences lead to vastly different approaches to branching and merging, which are critical for parallel development and managing features.
TFVC's branching model is typically more heavyweight. Branches are often created for major features or releases, and merging can be a complex process, especially with long-lived branches. Because branches are server-side entities, creating and switching between them can sometimes be slower. TFVC encourages a more structured, often hierarchical, branching strategy.
Git's branching is lightweight and fast. Branches are essentially just pointers to commits, making them inexpensive to create and switch between. This encourages developers to create short-lived feature branches for even small tasks, leading to more isolated development and easier experimentation. Git's merging capabilities are generally more robust and handle complex merge scenarios effectively, though conflicts still require manual resolution.
Workflow and Local Operations
The day-to-day workflow for developers also varies significantly between the two systems.
With TFVC, developers typically perform a 'Get Latest' to update their local workspace, 'Check Out' files before editing, and then 'Check In' changes to the server. Operations like viewing history or reverting changes often require server connectivity. The concept of a 'workspace' in TFVC maps server folders to local folders, and changes are tracked against these mappings.
tf get $/MyProject/Main
tf checkout MyFile.cs
tf checkin /comment:"Implemented new feature" MyFile.cs
Basic TFVC commands from the command line
Git's workflow revolves around local commits. Developers add
changes to a staging area and then commit
them to their local repository. They can make numerous local commits without affecting others. To share changes, they push
to a remote repository, and to get others' changes, they pull
or fetch
and merge
/rebase
. This local-first approach provides greater flexibility and allows for offline work.
git add .
git commit -m "Implemented new feature"
git push origin main
git pull origin main
Basic Git commands for local and remote operations