<p>As of Azure DevOps Server 2019, migration from Team Foundation Version Control (TFVC) to Git is a simple import command.  However, there are caveats to the migration due to how very different Git is in how it stores changes.</p>

<p><a href="https://docs.microsoft.com/en-us/azure/devops/repos/git/import-from-tfvc?view=azure-devops" rel="nofollow noreferrer">Microsoft has a great write-up</a> for this migration and if you have the newer version of Azure DevOps Server or if you're in the cloud, you don't need git-tfs.</p>

<p>But, a few highlights:</p>

<ol>
<li><a href="https://en.wikipedia.org/wiki/Git" rel="nofollow noreferrer">Git is distributed version control</a>, which means that you have a full copy of the files and all historical changes simply by cloning the repository to your machine.  You technically don't need a server, but if you have a team and collaborate, a server is needed to share changes with the team via appropriate Git workflows and branching.</li>
<li>Git is really good at storing text files and will only ever store a single copy of a file with each commit storing a snapshot of the differences in that file over time.  Binary files require storage of the full file for each commit that changes the file.</li>
<li>When binary files need to be stored in a Git repo, it's best to use <a href="https://help.github.com/en/articles/about-git-large-file-storage" rel="nofollow noreferrer">Git LFS</a> (Large File System).  This allows you to mark files as large/binary and Git will only track a reference to the file, not the actual file itself.  This keeps the repository small and nimble.</li>
<li>When you have an enormous repository (files/history) that is in the 2-4 GB range, you may need the Microsoft-contributed <a href="https://vfsforgit.org/" rel="nofollow noreferrer">Virtual File System for Git</a>, which Microsoft uses for its enormous 500 GB Windows code-base that developers all around the globe work from.  Contributions from Microsoft and the rest of the open-source community have done a great job of keeping Git commands performance-tuned for larger repos, but VFS for Git is a big leap for repos that cannot be small.</li>
</ol>

<p>If you are still running an older version of TFS that doesn't yet have the easy import option, that's OK.  Usage of git-tfs is a viable solution and Microsoft also has a <a href="https://docs.microsoft.com/en-us/azure/devops/learn/git/migrate-other-systems-to-git" rel="nofollow noreferrer">great write-up for how to approach this manual migration</a>.  In either case, there will potentially be work involved if your code-base if you stored a lot of binary files in TFVC compared to text/code.</p>

<p>What git-tfs is actually doing is creating a historical clone of your TFVC repository into a local Git repository by replaying the history and creating Git commits.  The tool can be used as a way to bridge a TFVC repo and Git repo, but you are better off fully migrating to Git and removing the TFVC repository.</p>

<p>Once you decide to fully migrate, it's best to do the migration in a few steps locally in the new cloned Git repo before pushing it to the TFS server as the origin.  This allows you to clean up any history of binary files that may be needed.  The <a href="https://rtyley.github.io/bfg-repo-cleaner/" rel="nofollow noreferrer">BFG Repo-Cleaner</a> can be used for this which can re-write history in the Git repo to remove all but the latest change to files like binaries, thus reducing the physical size of the Git repo on disk.</p>

CC BY-SA 4.0
2019-07-31T16:12:04.750Z
2019-07-31T16:28:15.670Z
2019-07-31T16:28:15.670Z
Sumo
<p>Answering based on using git-svn back in the day:</p>

<ol>
<li>The source of truth is <em>both</em> repositories. The point of <code>git-*</code> is to juggle this relationship without creating inconsistencies in either repository while migrating. You don't need a "Git server" until the entire team decides to migrate, because Git stores <em>all</em> the history in <em>every</em> copy of the repository.</li>
<li>All files are binary. Git handles files. Ergo, Git can handle binary files. What you may have heard is that if you have an absolutely enormous amount of files (in file count or data volume) in source control something has very likely gone wrong somewhere, and Git may be slower than central version control in some rare cases.</li>
</ol>

<p>My advice would be to simply try it. Create a local copy of your TFS repository using git-tfs, and run the Git repo through its paces without pushing the changes to your TFS server. If you run into any <em>specific</em> problems they would be appropriate for separate questions.</p>

CC BY-SA 4.0
2019-07-31T16:14:10.097Z
Sorry for the downvote, but all files are not binary.  Git can handle both text and binary, but needs to store a full copy of binary files for each commit because they cannot be diffed.  Git LFS helps with reducing the repo size by keeping the actual binary file separate and only keeping a reference to it instead.
Sumo
CC BY-SA 4.0
2019-07-31T19:55:55.627Z
All files are binary at a very fundamental level, but you're right about how Git stores them differently.
l0b0
CC BY-SA 4.0
2019-07-29T06:13:43.513Z
2019-07-29T06:13:43.513Z
l0b0
<p>We have a large TFS repository which we would like to migrate to git.</p>

<p>We are considering using git-tfs for a while, in order for everything to continue working while we migrate.</p>

<p>We have large (or small, but rapidly changing) binary files scattered throughout the code, which have been checked-in to tfs throughout the history.</p>

<p>My worries about git-tfs I have not been able to find accessible answers for:</p>

<ol>
<li><p>What is the source of truth for git-tfs? Is it a git server, a tfs server, or some hybrid, or none of the above?</p></li>
<li><p>If it is a git server, how would this affect workflow while knowing binary files exist?</p></li>
<li><p>We thought of using lfs, but not sure how this wuold play with git-tfs.</p></li>
</ol>

<p>I would love some light shed on this topic, as it would be quite pointless to migrate only to find out binary files make the new repo not usable</p>

CC BY-SA 4.0
2019-07-29T06:11:27.777Z
What is "lfs"? I guess you mean "LFS", but I don't expect you mean Linux From Scratch, which is the most relevant match I could find on the [first page of DDG](https://duckduckgo.com/?q=LFS&ia=web)
l0b0
CC BY-SA 4.0
2019-07-31T16:12:52.413Z
@l0b0 Git LFS is the Large File System feature that allows storing binary references rather than the actual binary files themselves in the repo.  This allows keeping the repo small with just text files and the differences over time in those files.
Sumo
<git><tfs><migration>
Migrating from TFVS to GIT using GIT-TFS
Gulzar
# Migrating from TFVS to GIT using GIT-TFS

(Asked by: username_0 on 2019-07-28)

We have a large TFS repository which we would like to migrate to git.

We are considering using git-tfs for a while, in order for everything to continue working while we migrate.

We have large (or small, but rapidly changing) binary files scattered throughout the code, which have been checked-in to tfs throughout the history.

My worries about git-tfs I have not been able to find accessible answers for:

1. What is the source of truth for git-tfs? Is it a git server, a tfs server, or some hybrid, or none of the above?
2. If it is a git server, how would this affect workflow while knowing binary files exist?
3. We thought of using lfs, but not sure how this wuold play with git-tfs.

I would love some light shed on this topic, as it would be quite pointless to migrate only to find out binary files make the new repo not usable

**Tags:** git, tfs, migration

> **Comments:**
> **username_1**: What is "lfs"? I guess you mean "LFS", but I don't expect you mean Linux From Scratch, which is the most relevant match I could find on the [first page of DDG](https://duckduckgo.com/?q=LFS&ia=web)  
> **username_2**: @username_1 Git LFS is the Large File System feature that allows storing binary references rather than the actual binary files themselves in the repo.  This allows keeping the repo small with just text files and the differences over time in those files.  

---

## 2 answers

### Answer by username_2 on 2019-07-31. Score: 1

As of Azure DevOps Server 2019, migration from Team Foundation Version Control (TFVC) to Git is a simple import command. However, there are caveats to the migration due to how very different Git is in how it stores changes.

[Microsoft has a great write-up](https://docs.microsoft.com/en-us/azure/devops/repos/git/import-from-tfvc?view=azure-devops) for this migration and if you have the newer version of Azure DevOps Server or if you're in the cloud, you don't need git-tfs.

But, a few highlights:

1. [Git is distributed version control](https://en.wikipedia.org/wiki/Git), which means that you have a full copy of the files and all historical changes simply by cloning the repository to your machine. You technically don't need a server, but if you have a team and collaborate, a server is needed to share changes with the team via appropriate Git workflows and branching.
2. Git is really good at storing text files and will only ever store a single copy of a file with each commit storing a snapshot of the differences in that file over time. Binary files require storage of the full file for each commit that changes the file.
3. When binary files need to be stored in a Git repo, it's best to use [Git LFS](https://help.github.com/en/articles/about-git-large-file-storage) (Large File System). This allows you to mark files as large/binary and Git will only track a reference to the file, not the actual file itself. This keeps the repository small and nimble.
4. When you have an enormous repository (files/history) that is in the 2-4 GB range, you may need the Microsoft-contributed [Virtual File System for Git](https://vfsforgit.org/), which Microsoft uses for its enormous 500 GB Windows code-base that developers all around the globe work from. Contributions from Microsoft and the rest of the open-source community have done a great job of keeping Git commands performance-tuned for larger repos, but VFS for Git is a big leap for repos that cannot be small.

If you are still running an older version of TFS that doesn't yet have the easy import option, that's OK. Usage of git-tfs is a viable solution and Microsoft also has a [great write-up for how to approach this manual migration](https://docs.microsoft.com/en-us/azure/devops/learn/git/migrate-other-systems-to-git). In either case, there will potentially be work involved if your code-base if you stored a lot of binary files in TFVC compared to text/code.

What git-tfs is actually doing is creating a historical clone of your TFVC repository into a local Git repository by replaying the history and creating Git commits. The tool can be used as a way to bridge a TFVC repo and Git repo, but you are better off fully migrating to Git and removing the TFVC repository.

Once you decide to fully migrate, it's best to do the migration in a few steps locally in the new cloned Git repo before pushing it to the TFS server as the origin. This allows you to clean up any history of binary files that may be needed. The [BFG Repo-Cleaner](https://rtyley.github.io/bfg-repo-cleaner/) can be used for this which can re-write history in the Git repo to remove all but the latest change to files like binaries, thus reducing the physical size of the Git repo on disk.


---

### Answer by username_1 on 2019-07-29. Score: 0

Answering based on using git-svn back in the day:

1. The source of truth is *both* repositories. The point of `git-*` is to juggle this relationship without creating inconsistencies in either repository while migrating. You don't need a "Git server" until the entire team decides to migrate, because Git stores *all* the history in *every* copy of the repository.
2. All files are binary. Git handles files. Ergo, Git can handle binary files. What you may have heard is that if you have an absolutely enormous amount of files (in file count or data volume) in source control something has very likely gone wrong somewhere, and Git may be slower than central version control in some rare cases.

My advice would be to simply try it. Create a local copy of your TFS repository using git-tfs, and run the Git repo through its paces without pushing the changes to your TFS server. If you run into any *specific* problems they would be appropriate for separate questions.

> **Comments:**
> **username_2**: Sorry for the downvote, but all files are not binary.  Git can handle both text and binary, but needs to store a full copy of binary files for each commit because they cannot be diffed.  Git LFS helps with reducing the repo size by keeping the actual binary file separate and only keeping a reference to it instead.  
> **username_1**: All files are binary at a very fundamental level, but you're right about how Git stores them differently.  

---

