Transitioning from TFVC to Git

I’ve had the opportunity to work for a company for 2 years now. The have a lot going on. They use TFVC, which works, but I quickly realized how much I like Git over TFVC .

I “grew up” with TFVC. Then a previous company decided to make the transition. It took us all a bit to get used to Git and learn it, but after using it we never looked back.

"Is it ever a good time to switch source control?"

~a knowing co-worker

I think that now is the time and here’s how I/we went about transitioning. (as I write this on 9/11/2020 we are in the planning and training phase)

Az DO = Azure DevOps tool (on premise or hosted)

TFVC = Team Foundation Version Control, the tool used for Source Control developed by Microsoft. It was the main tool I used from 2006 to 2016 or so. It’s better then SourceSafe was :-).

The Business Value Case / Hypothesis

We shouldn’t move to Git just because it is a shiny “new” toy (it’s not new anymore, but there is still that perception from teams that are using TFVC). We have to have a return on investment (internal training, planning, migrating builds/releases/codes, dealing with interruptions as we learn, etc). My hypothesis/value proposition is this

Moving to Git from TFVC will increase developer productivity, improve the code review process, reduce onboarding training costs, attract talent, boost moral/Net promoter score and encourage more continuous integration of code. The benefit gained and time saved will far outweigh the cost of time (migration planning, execution and overcoming obstacles).

I don’t have hard evidence, but from past experiences and people I’ve talked I see this as working well.

Steps to a Transition

Step 0 - Introducing the idea, gauge interest, is it the right time?

I found myself bringing it up on occasion (nudge, nudge), not to sow discord, but I really felt and knew that switching to Git would “improve daily work” and help developers to be more productive. It would also reduce training time for new hires, possibly help attract talent and make me more happy in my daily job. There has been a shift in culture in the last year and I’ve been able to bring up some safe to tries and have heard support from the team on wanting to move to Git.

I recommend proposing these changes as a “Safe to Try” experiments. Write up a hypothesis, steps you want to take and how you wil measure the results.

Survey

I created a survey (with input) on Microsoft Teams. We had about half respond. It was a normal Bell curve of responses. After the survey, we learned some things and felt like we could continue moving forward. Here are the questions we asked:

• What department are you in (Dev/QA/tech writers/other)?
• How would you rate your familiarity with Git as a source control tool?
  1. What is Git?
  2. I’ve heard of Git
  3. I’ve learned about Git, but haven’t used it much
  4. I’ve used Git in the past/present and am proficient in it
  5. I’ve used Git in the past/present and would like to help teach and train others to use it here.
• What is your reaction to the idea of migrating from TFVC to Git?
• Have you used TFVC outside of our company?
  • If not, how hard was it (how much learning time) to become comfortable with TFVC?
• What things should be considered for the Circle if more safe to try experiments are proposed for moving to Git?
  • Does your development process prohibit the use of Git?
• What source control tool would you prefer?
  • TFVC, Git, Subversion, something else
    • If you answered “something else”, what is it?
• Do you have other things you want to share?

Step 1a - Training

Put together training resources. I have a lot in my article Some Git Help .

Hold a workshop. Do a book club using ( https://git-scm.com/book/en/v2) . Learn together. Setup a Git playground repo with assignments.

Here’s a nice cheat sheet of TFVC to Git terminology .

Some Assignment Ideas

• Assignment - add your name to a readme.md
  • Get latest, create local branch, change, make commit, create PR, get feedback,
  • Before you complete the PR (Pull Request), add a short description about yourself (where do you live, what do you enjoy, family information, etc). Make the commit push to the PR
  • complete PR
  • What did you learn?
• Assignment
  • Experience how it’s faster
    • Rename, delete and move files in Visual Studio (no hang)
      • Do the same in TFVC in Visual Studio and compare
    • Switch branches
    • Git pull (or pull latest in VS)
      • Do the same in TFVC Source Control Explorer in Visual Studio and compare
  • What did you observe?
• Assignment - Deal with merge conflict, rebase from master
  • How to simulate?
  • Merging Changes Together - Using Git
  • What did you learn?
• Assignment - Merge into the next branch
  • Cherry-pick into new server branch
    • Cherry-pick your change to RC
  • What did you learn?
• Assignment
  • Amend Commit- Create a branch Add a commit, add another commit and amend it
    • In Visual Studio
    • In the command line
  • Reset to remove a commit - Create a branch, add a commit, reset that commit to remove it from the history
    • In Visual Studio - Git history
    • note: Make sure you are in the correct branch before using reset

Step 1b - Planning

Training and planning can be done in parallel. There are many questions to be answered and actions to be prepared for. Microsoft has a great guide that you should start with. They have a checklist at the bottom.

Here are a few questions to consider:

• Can you move smaller pieces at a time in Safe to Tries?
  • How long can you live with using TFVC and Git at the same time?
• Are you going to have a mono-repo or multiple repositories?
  • Mono repos have benefits and challenges. They can be organized by folders. Google and Microsoft are 2 examples of using mono repos. I think they are nice as you can use feature flags and continually ship the latest software. You don’t have to ask, is this code in that branch. You don’t have to continually merge code and wait for gated check in builds. You need a lot of automated test coverage for confidence.
  • Maybe you need multiple repos? It could be related to how you release things. Are they all released in a set with the same version or separately.
  • I don’t have the answer to this question, but I think that mono-repo is easier for the transition and you can break things out into different repos later if you desire.
• How are we going to handle branching?
  • Is time to move to Trunk Based Development ? (that would be my vote ;-)).
  • Checkout Microsoft’s guide I linked above for more ideas.
  • Coding Blocks had an excellent podcast conversation about the different branch workflows.
• Where should we store binaries, dlls(use Nuget), exe and zip files so we can get them out of source control (that will be backed up)?
  • If you don’t you will have a huge .git folder. You can also consider Git LFS .
  • Git starts to bloat
• What builds and releases need to be updated?
  • Create copies, delete the old ones after the migration
  • How are you handling versioning of dlls and the release?
  • Does this affect the installer creation?
  • Can you switch to building artifacts and passing them along, instead of rebuilding the code in each step?
• What branch policies are needed?
  • Branch Policies can be setup in Az DO and have a filter path to point at a folder
  • Ex: a PR reviewed by at least one person (or set people for a certain area of code) with building code and unit test coverage is required
  • https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies-overview?view=azure-devops
• Who are the Git “gurus” or “champions” that will help others and do trainings?
  • This is essential. People are going to have issues as the learning curve is bit steep. There need to be people available to help untangle bit branch messes and walk through the process. Eventually more will become comfortable with Git.
• Can you delete old branches?
  • not necessary for Git, but will make things a lot cleaner
• Can you clean up your repo and make it smaller?
  • look for zip files, dlls and exes (use Nuget instead)
  • use Git TFS , `git tfs quick-clone ..`` the repository and use WinDirStat to find big files
  • I found almost 1 GB that can be deleted or moved out of the repo!

Azure DevOps

• Is this a good time to migrate from on-premise Azure DevOps to hosted (or GitHub)?
• Do you need to arrange your Az DevOps Teams to align and combine?
  • If different connected products are in different teams and repository, it’s harder to use the tools to align work and search code.

Create a Road Map

The team is excited (most of them, others are telling you to make sure you don’t interrupt their work) and you’ve done some training. They need to know when the change will happen. This will give them motivation to understand Git and practice.

Step 2 - Practice before migrating

You can use Git for your daily work before the migration using Git TFS . This tool creates a bridge between TFVC and Git. You can use this to practice and/or keep your git repo up-to-date until the migration happens.

Start this as soon as you can. I was unable to migrate history (the project was more than 5 years old with lots of branches), but I did have all the history since I started using Git TFS.)

install with choco install gittfs (or run the installer from Github)

git tfs list-remote-branches (find the branch you want to put into Git)

git tfs quick-clone ... (clone the branch without history)

use git checkout master git tfs pull to get latest and history gets built up

use git checkout {branch} and git rebase master as normal to update existing branches

use git tfs shelve xyz (-f to overwrite) to get your changes into TFVC (use the shelveset and check that in)

Practice the migration. Microsoft has a guide on how to do the migration . You can use the UI or git-tfs. Maybe you should try both.

Step 3 - Continue to communicate the plan and do training

Send out reminders that this migration is happening. Be prepared, please send us feedback!

Consider a weekly study on https://git-scm.com/book/ru/v2 , a Teams/Slack channel, practice assignments.

Are the builds and releases ready to go?

Step 4 - Perform the migration

Are you using Git TFS or copy paste into your new git repo?

Check in, verify the builds and make sure you can release your code (release works, installers are created and work, etc).

Step 5 - Cleanup after the migration

• Make TFVC repos readonly
  • Remove write permissions Team Explorer -> Settings -> Security/Version Control
• Delete old builds
• Notify the team

Step 6 - Evaluate and continue to make improvements on the process

Are developers happy about the change? Consider another survey to find out the new constraints and attack those to improve.

Enjoy life more as a software developer and a team (saving time and avoid frustrations)!

Continue to learn about ways to use git.

Consider changing your branching strategy to increase velocity and reduce complexity.

I hope this was helpful. If there are things you think I missed, I'd be very interested in hearing from you.

What I learned and some adaptations from above

I’m back after the transistion. I wanted to share what I learned after the inital write up above.

Make sure you have a good team of people with different experiences that represent different areas and take advantage of the period of change to improve things.

• We had a great automation expert that changed many builds from UI to YAML builds in Azure DevOps.
• We found that we need to combine our Azure DO collections into one to enable better collaboration and planning (there were a lot of permissions and area paths to setup and planning how to move over work items).
• Setup a short standup with your smaller team to help you.
• For a large project, this is too big to take on for one person.

Communicate the plan often, share progress and get feedback.

Do many trainings. Expect people to put it off until the week before. It’s important to get manager buy in to encourage people to learn Git. Be ready to help those who are behind after the transistion.

Our leader directed us to do the transistion at once, instead of phasing it in. We blocked off several days and made the transistion. He didn’t want people to have to use 2 different tools and go to different places. This was more of an abrupt change.

Retrospective with the team

What went well?

• Several comments about how making this change shows that we can improve things.
• Git is soo much better then TFVC!
• I learned a lot for the team and we had great collaboration
• Teamwork
  • Open meeting during the transition where we were on the call all working together
  • Our leader was encouraging us and supporting us the whole way
• We are using Git
  • One PR across areas (ex: web, api, database scripts) (and multiple validation builds can be ran)
  • Policies
  • changed to Yaml builds (one file across branches, in source)
  • Git checkout task is faster
  • Short standup meetings to discuss things (3x a week, 15 minutes, daily for the few weeks before)
    • Teams chat channel
  • Development - Git channel
• Cleaning up the repos and deleted unneeded files (dlls, zips, exes)

What didn’t go as well?

• Cleaning out nuget.exe, other .exes and dlls took longer than I expected. It also caused some problems where we didn’t have good enough builds. Wrapping dlls in Nuget packages helped
  • TFVC doesn’t make it easy to make a lot of changes, I’m glad we are moving to git
• there were areas we still needed to clean up and will live as Git bloat
• Even after weekly trainings, there were some how didn’t take the time to learn and practice Git. They were busy with regular work. They are catching up.
• we left a branch in TFVC due to an upcoming release. We had to move from Git into TFVC for that branch and it took way too long for manual merging.
  • we should have done the work in that branch, then moved to Git, but some work was already in process

Change so we can improve next time?

• work more directly with developers of other teams
• plan the transition around release dates and sprint schedules (but don’t put it off so long you’ll never get to it)
• Take Dev and merge it through to QA and RC
• This made the migration different
• No commit to cherry pick for QA to RC
• Our branches are much different still
• Missed an opportunity to make them the same
• Train more to help with converting the builds to YAML (this was very beneficial but took a lot of time for one person)