Consider
There are a lot of things to consider when migrating from TFVC, a centralized version control, to Git, a distributed version control system. While it’s easy to think version control is version control, there are actually a lot of differences. Let’s walk through some of the things to consider after you’ve made the decision to migrate. If you still aren’t sure if which version control to choose, let us help you! We have an excellent article that walks you through why Git is a more effective choice: Choosing Git Over TFVC In VSTS.
Tooling
We all have tools we use to develop, build, and release our software. Git is the most popular version control system in use right now. It has a larger number of integrations with tools and IDEs that offer many features. Because of its popularity, there are many tutorials, communities and forums about its use and issues that might arise. It also has great mechanisms for the code reviews and branching / merging strategies.
Branching Strategies
One of the first things you’ll want to do is plan on picking a git branching strategy. There are a few different camps that people usually fall into. These do have pros and cons which I will briefly touch on. Git flow and Github flow are related strategies that describes how hotfixes, development branches, feature branches, release branches, all interact. A big downside to it, though, is the long-lived branches that can actually slow down development as you try to merge the code. Github Flow came about trying to simplify Git Flow. There is also Trunk-based Development or Single Branch model, everyone works on master and creates very short lived branches, usually less than a day. This minimizes the merging problem and makes sure the code compiles and tests pass on every check-in. Nebbia recommends Trunk-based development as does Microsoft, but this can depend on a certain level of maturity. Implementing Trunk-based development with a DevOps mindset, including automated tests and repeatable deployments provides the best benefits.
Restructuring
Migrating your source control can also lead to some code refactoring or restructuring. It was common to have many projects in a TFVC collection. It is most effective to have one project (or solution) per Git repository. If there is a lot of shared code, it might be good to pull out common functionality to its own project, this can lead to the creation of additional projects. These projects and shared libraries can then be made into NuGet packages or submodules.
Binary Files
Are there things that need to be cleaned up, like binary files, libraries, or executables? Moving to a new version control system is the perfect time to clean up things that might have slipped into the codebase. Binary files, like NuGet packages, npm packages, zip files, dlls can be removed and referenced in better ways.
History
In addition, Git stores file history and branches in a way that is quite different from centralized systems even if it appears similar. Do you need to migrate your version history? The gut reaction is, “Yes! Of course I want all my old history, we might need it.” A quick internet search will bring up scripts and tools to help migrate “ALL the data”. Sometimes can cause enormous issues, as well as being far from the truth. There are inherent differences between TFVC and Git. Branches in TFVC are the not same as branches in Git. TFVC stores branches as folders, a Git branch applies to the entire repository. The same is true for Tags: in TFVC you can “tag” files at different versions or points in time, in Git it applies to the entire repository. When migrating from TFS to Azure DevOps, there are some official tools to import and migrate the information, but Microsoft recommends that you don’t import history. So the real issue is we want the history to support our developers. Old version control history loses relevance very quickly. Immediately after a migration there is a need for history; however, as people start making changes, the old system will be referenced less and less. We usually recommend a “Tip” Migration. This means we migrate over the latest code into a new Git repository, sometimes many different repositories. A great migration path is moving from TFS to Azure DevOps on TFVC, then migrating to Git. You can bring all the history of TFVC without having to keep the old server running.
Time to Migrate
We have helped companies of all sizes perform their migrations. We can help you pick the most effective branching strategy, train the developers in Git, migrate your code into new repos, and setup the build and release pipelines. Let us help accelerate your migration.
