I admit it. I’ve been very late to the Git train. But I managed to jump aboard - and I love it. I’m sorry TFVC, we had many good years together. I always defended you and I couldn’t imagine how another version control did anything better than you. But then I tried out Git.

This post isn’t a detailed comparison between Git and TFVC. And it’s also not a step by step guide on how to switch from TFVC to Git. This post is targeted at all the TFVC-using developers out there who have never tried out Git - maybe you should give Git a chance and see for yourself whether you like it or not.

How to Set It Up

You can set up your own on-premise Git sever if you want to (or have to). But I’d consider using either GitHub for open source projects or Azure DevOps with a Git repository. (Btw., you can use Azure Devops with a GitHub repository as well.)

Do you use Visual Studio? No problem, Visual Studio supports Git.
Do you use Visual Studio Code? No problem, Visual Studio Code supports Git.

Let’s have a look at how to use Git for your daily work.

Yes, It’s Different

When you search for Git examples on the internet, you’ll notice that they all use console commands. The console is how you can use the full feature set of Git. If you’re used to the graphical interface for TFVC in Visual Studio, you might be discouraged. But, as I’ve already said, Visual Studio supports Git. That means, there’s a graphical interface for Git to. For your daily workflow, the graphical interface is more than sufficient. There’s no need to use the console if you don’t want to. Once you know Git better, you’ll find the console commands to be straight forward and easy to use.

A roadblock when coming from TFVC is the different vocabulary. Here’s a simple translation table (beware that it’s not always possible to accurately translate between TFVC and Git):

Action TFVC GIT
Inspect changes on the server - FETCH
Download changes from the server GET PULL
Commit changes - COMMIT
Upload changes to the server CHECKIN PUSH
Download and upload changes from/to the server - SYNC
Create a branch BRANCH BRANCH
Switch branch - CHECKOUT
Merge branches MERGE MERGE

As you can see, Git has some commands TFVC doesn’t have. That’s because Git works quite differently under the hood: TFVC is a centralized version control, Git is a decentralized version control.

TFVC: There’s one version control server. The clients download files from the server to their machine, make some changes and then upload the modified files back to the server. That’s pretty much it.

Git: Every client has its own version control up and running on its machine. Technically, there’s no need for a central server - that’s why Git is decentralized. However, in most companies you do have a central repository - that’s the GitHub or Azure DevOps repository.
Switching to a branch is called checkout. You can either switch to a local branch or you can checkout a remote branch. When you check out a remote branch, you’re not only downloading all the files. You’re also downloading all the file histories. That means, after the checkout you’ve got a complete copy of the remote branch on your local machine. Therefore, you don’t need a connection to the remote repository until you want to push your changes to the central repository. If you want to push something to the central repository, you have to commit your changes to your local repository first. Then, you can push your modified branch to the server.
Ok, so I can access the file history without a connection to the central server? That’s nice, but is that all? No, there are other cool things you can do when you’ve got your own version control running. For example, you can create local branches. You want to try something out? No problem, create a local branch. If it turns out to be good, merge it into your development branch. If not, delete the branch. Branches are a powerful tool. But you have to know that Git branches are way better than TFVC branches.

Why Git Is Better

I tried to explain what’s the principal difference between TFVC and Git. Now, I’d like to lay out why I think that Git is better than TFVC.

It’s decentralized: Having a local version control running is great. You can do a lot of cool things that way.

Branches are light: I already mentioned branches and how great it is to create a new branch whenever you want to. But when you’re used to TFVC branches, you probably don’t see how cool that is. That’s because TFVC branches are heavy. Every time you create a new branch, all the files from the source branch get copied to a new folder on your disk. That’s no problem for very small project, but for real-world enterprise projects, that can take some time. And if you’ve got multiple branches, it can also consume a lot of disk space. Because of that, you don’t have a lot of branches when using TFVC. You have a master branch and probably one branch for every release (V1, V1.1, V2, …). That’s it. Creating a branch is an endeavor. You don’t do it light-heartedly.
That’s very different with Git. Git Branches are light. When you create a new branch with Git, it’s only a pointer to a certain commit. That’s it. There’s nothing to copy.

Branch

Every commit points to its previous commit (its parent). Here, the first commit is 1, followed by 2 and so on. When you switch from one branch to another, let’s say from master to feature, Git restores the files in your working directory accordingly. That means, Git has to undo commits 5 and 3 and redo commit 4. Git does that in a very smart way. Changing branches is almost seamless. When you checkout a branch with Git, you don’t switch your working directory like you would do when using TFVC.

Pull requests are awesome: How do you merge branches with TFVC? First, you download both branches to your machine (Yuck!). Then, you merge the two branches locally und check in the merged branch. You can do the same with Git (but downloading the two branches is way faster). However, there’s another way. You can create a pull request.
A pull request is a collaborative merge. You don’t merge the branches locally, you create a pull request on the server. Now, your team members can review the merge and give you feedback before the changes get committed.

Do you want to know more about how Git works under the hood? Check out Pro Git.

A Typical Development Workflow with Git

Last, I want to show to you what a typical development workflow with Git might look like. Imagine you have to implement a new feature (user story, task, …). But you’re not on your own, you work together with some team members.

1) You create a new feature branch on the server.
Since you work together with others, it’s a good idea to create the feature branch on the server. If you work alone, you can also create a local branch and push the branch to the central repository later. Feature branches are great. You can implement a feature without interfering with the main branch. The feature gets merged into the main branch when it’s ready.

2) You check out the remote branch.
Now, you can start coding. Push your changes to the remote feature branch frequently. That way you can work together with your team members effectively.

3) Create a pull request.
Once you and your team members have finished the implementation, you create a pull request for your feature on the server. That way, you can get some feedback on your code.

4) Complete the pull request.
Once the pull request is approved, the feature gets merged into the main branch.

That’s it! Let’s do it all again with the next feature.

Do you still use TFVC? Do you think it’s time to move on to Git? Or is TFVC just the right version control for you?