Does TFS have the capacity equivalent of branching/forking in Git?

Question

We've got talking about branching and forking in Git and a teammate asked if there's something like that in TFVC (hereafter referred to as TFS). I explained that there is, although it's managed differently (shelfsets, branching, cloning, workspacing). In the end, we couldn't figure out the exact relation between these terms, though, and, despite googling the definitions and guides, we couldn't establish it reliably. I can admit that my competence within Git is limited and I'd guess that their isn't so hot neither.

I've never felt limited managing a project while working with TFS, so I'm assuming that Git's things have their equivalents in it. However, it possible that Git introduces a new trick that I'm not aware of. Please note that I don't mean Git introducing the same concept as already possible in TFS only delivered in an easier or more reliable manner.

Does TFS have the capacity equivalent of branching/forking in Git? What is it called?

Answer 1

Branches exist in both TFVC and Git, but they work fundamentally different.

A branch in TFVC is basically a fancy folder that you can check in to. Creating a new branch in TFVC is a copy-and-paste operation. The first check in to a new TFVC branch is enormous, because it copies all files from the parent branch into the new child branch. From then on check-ins can be scoped to the folder in which the branch lives. You are able to merge from child to parent, and from parent branch to child.

A branch in Git is just a pointer to a commit. Creating a new branch involves nothing more than creating a new text file in the .git/refs/heads folder. The name of the text file is the name of the branch. The contents of the text file is a Git commit Id. This operation does not require a network, nor does it copy files. This is the main reason why creating a branch in Git is an order of magnitude faster than TFVC.

Committing to a branch in Git writes a new version control record and advances the branch pointer to the new commit Id. Commit Ids in Git are generated based on the Id of the previous commit. This creates a data structure similar to a linked list where one commit points back to its previous commit (e.g. a directed acyclic graph). This allows branches in Git to share commits with one another. TFVC does not do this.

From a practical standpoint TFVC does not support forking. Tools exist to copy a TFVC repository check in by check in, but it rewrites the date and time that checkins occurred. It does not precisely replicate the history like "forking" a Git repository does. By the way, "forking" a repository is an idea GitHub came up with. A "fork" is really just a fancy way of cloning a Git repository for an entirely separate group of people. This allows multiple groups of contributors to have full control of their respective repositories, and serves as another way to isolate work beyond branching.

Teams issue "pull requests" to each other when they want to incorporate their work into another fork. This is a code review in Git parlance, and is a workflow outside of version control.

Git For Ages 4 And Up is a great video to watch if you understand some of the fundamentals of Git, like committing, creating branches, pushing, pulling, etc. While it won't explain the differences between TFVC and Git, the 1 hour and 40 minute video does a great job of illustrating what Git does under the hood using Tinkertoys.