Many of my fellow developers are now using the cloud-based Visual Studio Team Services after migrating from on-premises Team Foundation Server but still using TFS style repositories (Team Foundation Version Control, TFVC). They are locked into a rigid source control structure that is slowing down development and costing man-hours of effort to keep in place. Code quality is also suffering because developers are spending more time keeping code synchronized with source control than they are developing features. Even worse, they are not using any source control at all.

Be honest… How many of you are still sharing your original code sources with your teammates by saving to shared folders or walking them over on thumb drives? I know, I know… this is how we all used to do it back in the day and it seems like the easiest way. But what happens if your file gets corrupted or duplicated? What if you forget the thumb drive in your pants pocket only to be discovered as you pull it from the washing machine? With everything moving to the cloud and security becoming more of an issue, there has to be a better way.

Within Visual Studio Team Services, there needs to be a more streamlined and efficient source control policy. And the answer is Git.

This isn’t new… Team Foundation Server has supported Git since TFS 2013, which was released in October of that year – that’s four years ago! But many organizations are still not leveraging the additional power, flexibility, and quality control offered by Git. TFS and Visual Studio Team Services are excellent Application Lifecycle Management tools, but their Versioning Control capabilities are aging quickly. Git is the perfect in-place replacement option.

Reasons Why You Should Get with Git

1. Git is Distributed, Not Centralized
   This is the key difference between Git and TFS. Each developer has a full local copy of the repository. Two or more developers can be working on the same branch without worrying about who locked what file, or who is going to introduce the merge conflict. We have Pull Requests to handle merges cleanly (more on that later).
2. Branch in Seconds, Not Minutes
   Branching is the most flexible part of Git. For large projects switching branches takes seconds, compared to minutes for large TFS projects. Making new branches is so trivial that most Git workflows leverage this power to allow developers to work without blocking each other.
3. Pull Requests
   A pull request is a feature supported by all online Git platforms. It is a way to simulate the merge between two branches. This allows developers to visualize their changes, perform code reviews on a smaller set of data, and allows for a clear checkpoint before new features are accepted into QA or production branches.
4. Better Code Merges
   Git uses a three-way merge - it knows when branches started diverging. There is a base version of the file common to both branches, so you can see who changed what, even on lines that share changes. TFS, on the other hand, uses a simple text difference merge, so you lose that information.
5. Frequent Commits
   With Git, check-ins are no longer an all or nothing process. Commits are stored locally until you are ready to push them to the central server. This gives developers great flexibility for creating personal rollback points, letting them try something and easily revert to a known good state.
6. Work Offline
   Because of Git’s distributed nature, working offline is easily supported. You already have a full copy of the repository downloaded to your machine, so you can use all parts of Git to do your work. Compared to TFS, which requires an internet connection to check out, commit, shelf, or pull… your offline TFS options are severely limited.
7. Even Microsoft Has Switched to Git
   Microsoft has fully embraced Git, and are even working directly with the creators of Git to support mega-scale projects like the Windows kernel or Word. Microsoft is even hosting the Azure SDKs on GitHub to encourage community collaboration.

Using Git will simplify source control processes, increase the flexibility of feature development, increase code quality, and ensure smooth deployments. If you stick to the old ways, your development team will continue to struggle to react to changing requirements, have error-prone deployments, and spend excessive amounts of time undoing merge conflicts.

Want to work with a team who knows all the tricks of the trade? Check out our open positions on our Career page and apply today!