How my life changed when moving from TFVC(TFS) to Git

After working for the last three years with TFS’s classic source control TFVC, I recently moved to a new company and with that, to Git.

Before working with Git, I loved working with TFVC. I thought it was great and pretty much the most I can expect from a source control.

Git however changed the way I work with source control and even the way I think about source control.

This post is a small taste of what Git does and how my workflow changed accordingly. It is not a Git tutorial, but rather my impressions from it. I do link at the end to some additional resources.

Git is HARD to start with

Git has a pretty steep learning curve. Crazy steep when comparing to TFVC (Original TFS) or Subversion (SVN).

Things are not intuitive in Git when starting. At least they weren’t for me after working for so long with TFVC and SVN. And the reason is that there is a core difference between them.

To work with Git, we have to understand how Git thinks. And at the core, we have to understand DVCS.


Git is a Distributed Version Control System – DVCS. Whereas TFVC is Centralized Version Control System – CVCS.

DVCS means each developer has the entire repository, including the entire change history on his/hers local machine. So the developer can see changeset history offline or commit (check-in) changes offline to his local repository.

In CVCS, the developer has a copy of the repository file system on his machine. So offline actions like commits (check-ins)  and seeing history are impossible since the local repository can’t save “changes”.

So what are the implications of this?

In Git, everything is done locally

Since the entire repository is local, we do everything locally. This includes, but not limited to:

  • Commiting changes (Check-in)
  • Viewing commit history
  • Creating a new branch
  • Merging branches
  • Moving to a different branch
  • Deleting branches
  • Reverting older commits

Of course, at some point we have to sync our changes to the remote repository (“Push”).

“Check-in” in Git is divided into 2 parts: Commit and Push.

This is actually a big deal. It allows a much better workflow for us developers. I can now commit locally whatever I want – Ugly code, comments and work in progress. The other developers won’t get those changes. And when my code is nice and clean, I can Push all my commits to the remote repository.

Another concept in Git is Staging. This is a bit like Included / Excluded changes in TFS. Only staged files will be committed. Which is convenient since I usually have modified configuration files that I don’t want committed.

Git is fast, really fast!

Committing (Which is like check-in to the local repository) takes less than a second on my PC. Blame (Annotate) , viewing history or filtering by commits is incredibly fast. This is partly because in Git everything is done locally. But also, because of Git’s unique way to save the repository. Git works with snapshots instead of with changes.

Branches and Merges are really where the power of Git over TFVC shines.

Branches in Git

In TFVC, Branch will create a new directory with a copy of all files and directories of the parent Branch. For a developer to work on that new branch, he will have to copy that directory to his hard disk, essentially having another folder with the source code.

In Git, each branch, is not a copy of the files from the parent branch. Instead, it’s simply a pointer to the Commit in the parent Branch from where we created our new branch.

So when we want to work on a different branch, we tell Git “Move to another branch” (Checkout command) and Git will change our working area to match the desired branch. This is very fast since it’s done locally. Git already contains all the branches on the local machine.

Merging is a lightweight operation. We can merge any branch to any branch. We can merge the entire difference or a specific Commit. Git will find the “Base” Commit where the branches split and allow us to resolve conflicts (This is the same as in TFS)

A good practice with Git is to create a new branch to work on a big feature. Eventually, merging that branch to the master branch and discarding the new branch entirely.

Here’s a good tutorial on branches in Git.

 Tooling and Git command line

Git is a command line based tool. You can do everything with the command line, and I know there are a lot of Git users that advocate that. However, nowadays there are some excellent tools that provide a nice GUI to work with Git. One such tool is Git Extensions.

Also, there’s integration with Git in Visual Studio, but I find Git Extensions to be more convenient.

Git Extensions actually gives you a Console window where you can use Git command line with several Linux commands like Grep. This is very useful. Especially when seeing answers in StackOverflow, I can just copy-paste them to my console window.

I don’t see why anyone would choose to use Git with the command line, when there are such great free tools like Git Extensions.
But then again, be careful taking advice from the internet 🙂

My transition to Git

Once I got over the initial Git shock, my working flow became faster. There are a number of reasons for that. First of all, Git itself is really fast. Second, with Git I do local commits which saves me time. I can commit my work in progress code without worrying it’s buggy and will disrupt another developer’s work. So I don’t have to save my pending changes for a long time until I’m sure whatever I’m doing is good enough.
This is one of those things that I never realized I needed until I started working this way.

The third reason Git made my life better is branches. Creating merges and working on a side branch become a part of my workflow.


I am definitely falling in love with Git.
Full disclosure: I also fell in love in TFVC and TFS when I started working with those.

Git is faster and more powerful than TFVC or SVN. It rapidly becomes the world standard to source control system.

Git is also pretty hard and I’m sure many a developer spent a lot of hours trying to decipher why Git does what it does. TFVC is definitely easier to start with and more intuitive.

I don’t think moving to Git is necessarily the right choice for everyone.

Here’s my very opinionated advice about organizations considering moving to Git:

  • When starting a new project with no developers yet, use Git.
  • If you have a small team with at least one strong developer experienced with Git, move to Git.
  • If you have a big team working with TFVC and not enough people experienced with Git, moving to Git will be costly. But maybe it will pay in the long run.
  • In the end, it’s all about quality of people. Git is more powerful but harder. If you have superstar developers on your team, they will figure it out. Move to Git.


7 thoughts on “How my life changed when moving from TFVC(TFS) to Git

    1. Post author

      Very cool, I liked it! Gives a nice structure for everything.
      I can follow that branch model without using the Git flow commands though… Git has too many commands as is 🙂

  1. Alon Perel

    Sweet, sounds much more robust and less prone to people getting in each other’s way, as well as a faster way to getting to know the nooks and crannies (‘s how it sounds like, xD).

    1. Post author

      Very true. With just one small price – A steeper learning curve and more room to make mistakes

  2. Pingback: Creating an ecosystem with Continuous Integration, Installer and Deployments for a WPF / UWP application - Michael's Coding Spot


    “Once I got over the initial Git shock, my working flow became faster.” — But I am willing to bet it also became more isolated (there is much more to the “distributed vs. centralized” than where the repository lives.

    Now there are times when isolation is good. The perfect example is different vendors each producing their own version of Linux.

    But in a highly integrated team, there are many things that are centralized, and the isolation caused by Git* is likely to have a negative impact on all of them.

    david(dot)corbin(at)dynconcepts(dot)com for further information.

    * Git can be configured so that things are tightly integrated (meaning all team members see all changes within minutes of them being made, the repository is *always* protected against broken code, changes are reliably associated with other artifacts, et. al.) – but when this is done all of the advantages of Git are basically disabled – A distributed tool has been coerced into behaving like a centralized one.

    1. Post author

      David, I see your point and agree that with Git’s branches and local commits, it’s very easy to work SOLO without conflicts from other developers. Whereas a centralized source control sort of makes you sync with everyone else as soon as possible. I see this as an advantage to Git since you have the flexibility to choose how often you’ll merge to the main development branch.

      For me personally, I try to merge back as often as I can. So I will create a branch for a new feature, but will make sure to do back-merges (or rebases) from the main branch to my feature branch every couple of days to have my code as close as possible to the other team.


Leave a Reply