This post is provided by App Dev Manager Tina Saulsberry who shares a few tips and resources to streamline enterprise migration to Git.

Microsoft has moved its largest code repository to Git. We migrated our 20+ year old Windows repository, with over 4 million files and 300GB of data. This isn’t the only repository that we have on Git, in fact we are bringing all of our source code and teams over to VSTS & Git. During this migration we picked up a few lessons and built tools to scale Git. Below are some considerations when migrating to Git:

• Leave your history behind and perform a tip migration. To perform a tip migration, take the latest source code, migrate to Git and leave the history behind. Understand that when migrating from a centralized repository like TFS or VSTS to a decentralized repository like Git, many concepts do not translate very well between the two. Concept of renaming doesn’t exist in Git; branches, tags, and labels are at totally different scopes between the two types of repositories. There are tools on the market that try to interpret the history and feed it to the decentralized system but for compliance & regulation purposes, we recommend keeping the centralized system around for history.
• Consider using Git Large File Support (Git-LFS) to support large files. Git doesn’t handle large binary files very well. If your repository has large binary files (images, videos, etc), instead of migrating them directly into your Git repository take a look at extension Git-LFS. Git-LFS shards your binary files into a separate Git-LFS space, leaving your Git repo slim, pristine and fast. You can still manage your large files with Git, you just won’t have a bloated Git repository.
• Consider using Git Virtual Filesystem (GVFS). With 4 million files in our Windows repository we needed the ability to clone a repo, checkout and get to work quickly. Git was unusable on its own, cloning took over 20 hours to complete and checkouts took 3 hours on our Windows repository. Microsoft developed GFVS to handle our large repositories to make working with Git more manageable. GVFS downloads the files it needs immediately and pages everything else in as needed or on-demand. Git + GVFS on our Windows repo decreased the clone time to 90 seconds and checkouts to 30 seconds.
• Enforce policies like pull requests. Enterprises with a large development team (over 200 developers) working in the same repo will start to notice contention problems when pushing their changes to the integration branch on the server. Developers get into a vicious cycle of trying to push their changes to the server only to find out that someone else has already pushed their changes. The developer must then download the latest code from the server, merge in their changes then try to push to the server once again and hope that no one has beaten them to the punch. With pull request there’s no contention on pushing files to the server as seen with large teams. All the merging of the files happens on the server, there’s no need to pull down others’ changes locally. Developers will only need to merge locally when there are conflicts.

I encourage you to check out the Channel9 videos by Edward Thomson, Program Manager for VSTS, for additional information. His sessions on Git at scale, Git at scale with Git Virtual File System and Using pull requests with VSTS are very helpful. Engage your ADM and keep an eye out for other features we have in our pipeline to help enterprises scale Git.

Premier Support for Developers provides strategic technology guidance, critical support coverage, and a range of essential services to help teams optimize development lifecycles and improve software quality.  Contact your Application Development Manager (ADM) or email us to learn more about what we can do for you.