How to overcome your TFS hangover and start a new life with Git
If you are reading this article then there is a good chance that you are a –
1. Microsoft TFS(Team Foundation Server)’s or Azure DevOps’s (formerly known as VSTS) TFVC (Team Foundation Version Control) user for a good amount of time.
2. And now with the huge popularity of Git because of all of its goodness and Microsoft’s first class support to Git with Azure DevOps your project team has decided to move the source control to Git from TFVC.
3. And as a result of which you as a poor developer struggling day in and day out figuring out how to Get Latest, Check In, Check Out, Shelve with Git. None of your well known TFVC actions are there which you have learnt and used to for all your life.
This article is for those developers who have been using Visual Studio with TFVC for a good amount of their programming career. Now because of whatever reason (obviously for good reasons) they have to switch from TFVC to Git. Moreover for those who are in their First Week of Git Pain phase.
In next few minutes or so I will take you through various scenarios to understand the differences and commonalities between Microsoft TFS/ Azure DevOps’s TFVC and Git world with respect to most commonly used source control features that a developer uses every day.
This is an attempt to help you re-map your brain and ease out your hangover from TFVC so that your journey to Git becomes smoother.
A little disclaimer: The title of the Story says ‘TFS hangover’, but technically I wanted to mean Microsoft Team Foundation Version Control (TFVC) here. Reason behind using TFS instead of TFVC is — in general, I think most of us call it TFS and very few of us actually call it as TFVC in daily usages. It is like calling a copier machine as ‘Xerox machine’ although we want to mean it as photo copier machine.
First thing first — lets download the code from server
First thing First – you’ve got a source control server, unless you download a copy of the code in your local system, you can’t start developing.
To download the source code from TFVC — what you used to do so far was – connect to the Team Server and configure the workspace with a local path to download the source code. This was done simply by pointing to or by creating a new folder in your local disk and getting latest version using Map & Get.
Now in Git it’s different. It’s all about Cloning. Memorise the term Clone, you are going to use this term a lot going forward. Clone is similar to downloading the server data to your local Machine.
To clone the server Repository (repo) to your local – Go to Team Server >> under Local Git Repositories section >> click on Clone >> Provide Git server url of the repository and mention a local path where you would like to download your source code. Now hit the Clone button, it will clone the server repo to your local drive.
Git works in a bit different way, here everything is local and local Git repo is the first-class citizen of Git world. It allows you to commit your changes to local Git repository as many times as you want and let you develop locally in a disconnected fashion.
In TFVC world every Check In has to be at the server, but in Git you commit all your changes to local repo first and when it’s a time – you Sync it with the server repo.
So, in a single sentence just remember that in Git world you have to Clone the repo, not Map and Get whenever you want to download the source code for the first time.
Where did the ‘Check In’ option go?
Okay now that you have cloned (crossed the first hurdle) the repo in your local, you must be tempted to start making the changes in your code.
Now that you have made some code changes, you want to Check In the code, you just right clicked on the source file — but what a surprise the Check In option is missing.
In TFVC world every time you want to save your local changes to the server you do Check In, but in Git world it’s Commit + Push.
To commit your all of your changes go to Team Explorer >> under Project section you will see Changes section (This is similar to TFVC Pending Changes). You will see all your changes here in this section.
You need to Stage the necessary files that you want to commit. To do so right click on the files and select Stage. All of your changes will start appearing in Staged Changes (This is similar to TFVC Included Changes) section. Files that you do not want to commit (unstage files) will be in Changes section now.
Now that you know what you want to commit, just hit Commit Staged button. This will commit your code to the repo (which repo is this? server repo or local repo? — well I will tell you in a bit)
Now that I have committed my code, why can’t I see it in server?
Once your code is committed you went back to solution explorer and confirmed that there is no file without Lock symbol. You must be thinking now that all of your code is committed to server, isn’t it ? but did you notice this warning which popped up just after hitting Commit Staged button ?
Read it aloud — it says Commit created locally. As I have mentioned earlier, in Git world everything gets committed to local first. It means your first commit got committed to your local, that’s why you couldn’t see it in the server.
Now you need to Sync your changes so that it gets actually Committed to Server.
To sync your local changes to server you can hit Sync in the above warning message if you still have it popped up, or alternatively you can go to Team Explorer >> under Project section >> Sync - here you will see your commit is seating under Outgoing Commits (it says “Outgoing Commits” because it’s supposed to go out from your local to the remote Server repo)
Now to Sync it just hit Sync, this will Sync your local changes to your Server repo and there shouldn’t be any Outgoing Commits pending.
Be happy when you see this message -
Now all of your changes will start appearing in server version of the codebase.
In git world you used to Check In in one show, but what happened to Git, why can’t you commit at one shot?
Well there is a way to do that. If you want to Commit your local changes to Server in one shot then you can click the down arrow of the Commit Staged Button and use either Commit Staged and Push or Commit Staged and Sync. First one will commit your code to local and then commit the changes in the server whereas the later one will do the first step + sync your local repo with the server version code.
Where is my old friend ‘Get Latest Version’?
Did you see your good old friend ‘Get Latest Version’ option anywhere so far? You grow up hearing a lot Get Latest from TFS which gets all your latest code from server to your local, but here in Git it’s completely missing. What a shock!!! You must be thinking now how on earth a source control works without a Get Latest option?
Well, while Syncing your code, did you notice some other options like Pull, Push and Fetch? Yes, Pull and Fetch are those two little things who are going to suffice your Get Latest needs.
You must be thinking now Pull and Fetch are almost synonymous but why they are two separate things? also you must be thinking – If Sync pushes my code to server then what’s the need of Push again?
Well let’s have some Git lesson to clear out this dilemma -
Fetch — gets the latest code from server for you but doesn’t merge it with your local.
Pull — downloads the latest code from server plus merges with your local code (Similar to TFVC Get Latest Version). Since Pull tries to merge remote code to your local, it may incur merge conflicts.
Push — pushes (commits) your local changes to server. This doesn’t sync back your local with server’s latest code that might have been updated by others in your team.
Sync — pushes your local changes to server and syncs your local with other remote commits committed by others. Sync makes sure that your local is always synced with remote (server). Be cautious while syncing, make sure your outgoing commit contains legit commits which you want to push to server.
I don’t see the Source Control Explorer, and where are my code branches?
By default, Git gets initialises with a Master branch. From master branch you can create multiple branches as per you need. Normally people create a develop branch at minimum where all ongoing development happens during a release cycle and when it’s time to release, develop branch gets merged to master and from master the release gets created.
To see the server branches as well as your local branches you need to navigate to Team Explorer >> under Project section >> Branches
Your local branches will appear under the Repository name with orange Git icon. Currently checked out branches will be highlighted.
Server branches will appear under remotes/origin section. You can right click on the remote branches and create a new local branch from any one of those and the local branch will start appearing under the repository as above.
Visual Studio task bar gives you some awesome information. At any given time, it shows you which branch you are working with, name of the Git repository, how many files are pending commit and number of outgoing commits.
I have to develop a feature in a feature branch, what’s the easy way to manage my branches?
If I’m not wrong then I’m sure you follow Agile methodology in your project (everyone wants to give feedback).
Remember Feature branch in TFVC? Feature branch in TFVC is a replica of a parent branch with same shape and size. If you need to develop in a feature branch you have to download the whole branch in your local machine first, meaning if the server branch is of 2 GB, it will download 2 GB of data in your machine and it will take its own sweet time to download based on the network speed.
In the world of Git, it’s completely different, it’s super-fast, lightweight because and it doesn’t download the whole thing in your local machine. It just creates a new reference for your feature branch (.git folder under C:\User ) which makes it extremely popular in developing with feature branch in Git. You can create branches in Git with no time unlike it is in TFVC.
The reason I was making sure that your project is in Agile because if it’s Agile then there is a good chance that you do feature based development. If you do feature based development then you may need to create a new feature branch for your feature development. Apart from this also since Creating of a feature branch is very easy and blazing first it’s considered to be a good practise to have a feature branch for each and every developer. Once you are done with the feature development then you can sync the branch with remote branch and delete the feature branch from Local as well as from the server. This helps you to work in an isolation mode without impacting anyone’s work.
If you are working in feature branches then at minimum you have to create your feature branch from remote branches and delete those feature branches when work is done. The whole feature branch management is a daunting task, especially when you need to remember all the Git commands. But here we are not going to remember all the commands to start with, we will use a nice little Visual Studio extension GitFlow which can save you from all of these. I call GitFlow is a saviour. You can download it from Visual Studio Marketplace.
To start using GitFlow you need to first Initialise it. Once Initialised you can create your first feature branch by using Start Feature option. Once you create the feature branch it will first create the branch on your local and will be checked out for editing. This feature branch will now appear under feature section in the branch explorer.
Once you are done making your changes, do Commit Staged and Push. This will commit your changes in your local feature branch and then it will create a feature branch in the Server.
In a feature branch development, it doesn’t end with committing your code to server’s feature branch only. You have to merge it to the parent branch too. But wouldn’t you like to share the code with your team for review before you merge it to the parent branch?
I want to share my code for review, but I don’t see ‘Request Review’ option.
You developed some feature and committed to server’s feature branch, now you want to share your work with your team for code review, but where is the Request Review option? Well in Git world it’s called Pull Request. You must be thinking now that — ‘Pull is for getting latest from server. I want to request for review but again why it’s called Pull Request? ’— it’s called Pull request because you are requesting to Pull your changes from your feature branches to the parent branch.
To create your pull request, navigate to Team Explorer >> under Project section >> select Pull Requests >> New Pull Request — this will open your TFS portal/ Azure DevOps portal in a browser. You need to now select the target branch on which you want to merge your feature branch’s code after code is reviewed, select the reviewer and Create the pull request.
Once the code is approved by the reviewer you can merge your code (feature branch to parent branch) by Compete merge option and you can optionally delete the server’s feature branch after the merge.
You can alternatively delete the server and local feature branch from the Branch Explorer in Team Explorer of Visual Studio or let GitFlow do the heavy lifting for you. (Navigate to GitFlow >> Recommended actions >> Finish Feature).
At this point in time your code is reviewed, and merged to the server’s parent branch from your feature branch and after that using GitFlow you have cleaned up your feature branch from local as well as from server. You are all set to start developing your next feature.
I have got an emergency bug; how do I shelve my current work and start fixing the bug?
What if you are working on some feature and you have made changes to a lot of files which are uncommitted? All of a sudden, a bug picked up priority and you are assigned to fix the bug. You have to suspend your current work now and start working on the bug. But what would you do with the uncompleted code files that you were working for the other feature?
In TFVC world you could just Shelve the files, undo the pending changes and then start working on your bug. Once the bug is fixed and Checked In you can Find the Shelveset then Unshelve it and resume your previous feature development work.
In Git world there is nothing called Shelve, in order to Shelve your changes, you have to use Stash instead. Stash comes out-of-the-box with Visual Studio 2019. If you are a VS 2017 user then you can download this extension from here.
To Stash your changes, write a comment for your stash, use Stash all and Keep Staged option. This will create your stash under Stashes section. To resume working with the stashed files — right click on the stashed item and use Apply and Restore Staged. This will unshelve your files and files will appear in changes section. From here you can Stage the changes and commit your code.
Final prescription — a cheat-sheet
We have covered many commonly used TFVC and GIT scenarios, having said that are at the end of your TFVC hangover treatment consultation. Finally, I would like to recommend you to have the below chit-sheet handy for SOS usages —
Wrap up
Git and TFVC are both built differently and they are fundamentally different things. Git is built around the concept of distributed and decentralised source control system in mind whereas TFS/Azure DevOps’s TFVC is more of centralised version control.
Since TFVC and Git are conceptually different, a TFVC user just can’t simply unload all the TFVC concepts from his/her mind and start using Git from day one. It takes couple of days to a week to get familiarised with various Git operation and remap the brain.
In this article all the above scenario explanation and comparison was intended to ease out your TFVC hangover a bit, and to help you get started and cope up with First Week of Git Pain while transitioning to Git from TFVC.
If you are struggling with some other scenarios then don’t hesitate to comment.
