i

Description

Aiguillage ferroviaire vu de près, où la voie se sépare en deux.

Source

Xunil · original page

Licence

PD Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Git vs TFVC: compare, migrate, coexist

Compare Git and TFVC with ratings and context, without dogma.

In brief

• Compare Git and TFVC in a rated and contextualized way, without dogma.
• Choose based on scenarios (team, repository, permission constraints, binaries, audit, CI).
• Understand TFVC → Git migration paths with or without history, the tools (git-tfs, git-tf, Azure DevOps import) and their limits.
• Describe coexistence of a local Git repository on top of an official TFVC repository, and its risks.
• Have a step-by-step migration plan and a list of pitfalls.

Prerequisites: Git In Depth, TFVC in Depth.

On this page

1. Two philosophies
2. Equivalent vocabulary and actions
3. Rated comparison
4. Scenarios
5. Should you migrate
6. Migration options
7. Tools
8. Coexistence of local Git and official TFVC
9. Step-by-step migration plan
10. Migration pitfalls
11. AI’s Contribution
12. See also

Level: 🟡→🔴

Two philosophies#

🟡 Practical level

TFVC thinks “the server knows”; Git thinks “history is a graph that everyone owns.” This reversal explains most migration difficulties: no more checkout, a commit is not a check-in, branching becomes ordinary, history can be rewritten locally.

Equivalent vocabulary and actions#

🟡 Practical level

Rated comparison#

🟡 Practical level

Expert ratings out of 5. Context: team of 5 to 30 developers, SQL + Power BI + scripts project, repository of a few GB, Azure DevOps (Server or Services), deliveries by product versions. Contextual assessments (see RATING).

How to read: Git clearly wins on “ecosystem” dimensions (CI, review, AI, hiring, longevity); TFVC keeps the edge on path-based permissions, binaries, simplicity. Neither wins everywhere, and an average score would be misleading: weight based on your constraints.

Scenarios#

🟡 Practical level

Should you migrate#

🔴 Expert level

Migrating has a cost: training, tooling, risks to history and work item links, disruption of habits. Legitimate triggers:

1. Need for tooled code review (pull requests, policies) to raise quality.
2. Need for modern CI/CD on every change.
3. Longevity: moving away from a frozen engine (see 03).
4. Hiring and upskilling.
5. Use of development AI native to Git platforms.
6. Need for low-cost task branches.

Non-triggers: “Git is trendy,” “others are doing it,” one dev annoyed by a single command. Measure: conflict frequency, review duration, delivery lead time, onboarding. A team with no review practice under TFVC will not suddenly have one under Git.

Migration options#

🔴 Expert level

Microsoft recommends “tip” migration, with at most limited history (native import tool caps at 180 days): full history is hard to replay faithfully and rarely consulted.

Key structuring decisions:

• Branches: one TFVC branch = one folder; dead branches should be ignored. Often you migrate Main + live release branches.
• Authors: mapping table DOMAIN\name → Name <email>.
• Work items: links to changesets become obsolete; you can keep numbers in migrated commit messages for search.
• Labels: become tags (if imported); verify they do not mix versions.
• Large files: sort them out (LFS? move out of repository?).
• Encodings/line endings: normalize before import (06); otherwise the entire history appears “modified” in the first normalization commit.

Tools#

🔴 Expert level

Example use of git-tfs (Windows workstation, Visual Studio/Team Explorer installed):

# Full history of a branch
git tfs clone https://tfs.exemple.local/tfs/Collection $/Projet/Main D:\Migration\Main --branches=none
# Partial history: starting from a changeset
git tfs clone https://tfs.exemple.local/tfs/Collection $/Projet/Main D:\Migration\Main --changeset=45000
# Authors
git tfs clone ... --authors=auteurs.txt
# Cleanup before publishing: remove git-tfs-id metadata if not desired
git filter-repo --message-callback "..."   # as needed
git remote add origin https://dev.azure.com/org/projet/_git/mon-produit
git push -u origin --all

Coexistence of local Git and official TFVC#

🔴 Expert level

Common situation: the organization requires TFVC as the official archive (builds, audit), but the team wants Git benefits at its own scale: frequent commits, branches, stash, bisect, blame, AI tools. Practical solution: a local git repository with no remote in the same folder as the TFVC workspace.

How it works:

• Work and commit in local Git during the day (atomic commits, fine-grained history).
• At milestones (end of task, end of day), archive in TFVC: tf add new files, tf checkin with a link to the work item.
• The two histories coexist: Git is the fine draft, TFVC is the official truth.

Rules to make it sustainable:

1. Two aligned exclusion lists: .gitignore and .tfignore; a file ignored by one must be ignored by the other (except deliberate cases). See 03.
2. .git folder excluded from TFVC (never add it to source control) and internal TFVC files ($tf, .tf) excluded from Git.
3. Line endings and encoding normalized the same way on both sides (.gitattributes + TFVC convention), otherwise every round trip causes noisy diffs.
4. Dates and authors: the TFVC commit does not carry over Git history; keep meaningful check-in comments, because that's what audits will see.
5. Read-only permission in TFVC workspace: in a server workspace, after tf get, files are read-only and require tf checkout before Git can modify them. In a local workspace, files remain editable: edits are detected automatically, and tf reconcile /promote turns additions/deletions made outside Visual Studio into pending changes.
6. Single write direction: never automatically “sync” TFVC → Git → TFVC without rules; the safest approach is tf get then git add -A && git commit (“what TFVC delivered to me”), then work, then check-in.

Step-by-step migration plan#

🔴 Expert level

Typical plan for a team of 10-20 people, over 6 to 12 weeks (orders of magnitude, depends on size and preparation):

1. Scope (1 week) — Decide: migrate what (Main only? + releases?), with what history, for what measurable benefits. Inventory: collection size, large files, active branches, policies, builds, work item links. Sponsor identified.

2. Prepare (2-3 weeks) — Clean the repository (binaries, caches, duplicates). Normalize encodings and line endings. Write .gitattributes, .gitignore, branch/message conventions, branch policies (PR, validation build). Build the author mapping table. Secure permissions (groups, split repositories if folder-based permissions).

3. Pilot (2 weeks) — Migrate a non-critical scope (or a copy of production) with the selected tool; compare content to the reference changeset (file list + checksums) to prove fidelity; replay a full delivery (installable package) from the Git repository; measure clone, status, build.

4. Train (continuous) — one 3-hour hands-on session: simplified object model, daily cycle, PR, conflict resolution; TFVC→Git cheat sheet (equivalences); one “Git champion” per team.

5. Switch (1 weekend or 1 quiet day) — Freeze TFVC (read-only permissions), final migration, verification (files, tags, a few sensitive files opened manually), update pipelines, hooks, documentation, links. Clear communication: “starting Monday, commit here.”

6. Consolidate (4 weeks) — Close support, retrospective, metrics (conflicts, review duration, lead time), remove old workspaces, archive TFVC (read-only, retained).

Success criteria: all current product versions can be rebuilt from Git; build pipeline is green; nobody commits to TFVC anymore; team is autonomous on routine operations.

Migration pitfalls#

🔴 Expert level

AI’s Contribution#

Typical prompt: “Here is a detailed tf history excerpt. Produce a CSV tfs_account;name;email without inventing any address: leave blank if unknown.” AI does not replace the decision to migrate, the fidelity verification (checksums), or accountability for archive compliance. See AI in Planning and Version Control Tools.

See also#

• Overview · Git · TFVC · Branching Strategies · SQL and BI
• Azure DevOps Server (ex-TFS) in Depth · Comparison of Planning Tools
• Matrix: Version Control and Branches
• CI/CD for data: foundations, datamarts, pipelines, and reports · Glossary

✻ Written by Claude Sonnet 5.5