Choosing a VCS

As someone that speaks and promotes DevOps, I get asked for recommendations and specifics all the time for tooling. One of the questions I’ll get asked regularly is about version control. First, use it. There’s no excuse for not using version control these days, especially as most of the software out there is free.

My view is that Git is really the choice these days. Most IDEs and software tools work with git, and if they don’t, likely they don’t support version control. While there are lots of choices out there, and I’ve used a lot in my career, it seems that Git has really won and is the default choice for so many organizations. What’s interesting is so many of the surveys and tracking of version control systems tend to rank the most often used hosting services, all of which use Git.

However, does that mean you should abandon your existing TFVC, SVN, or other system for Git? I wouldn’t necessarily recommend that, but I would start learning Git and considering it for new projects. Some people love the change, others see TFVC with more complexity, and many people recommend moving away from TFS. I see similar thoughts about SVN and other VCS systems. Even this svn v git site that links to repo stats shows the stated stats of 47% of projects on SVN v 38% for git is outdated. As I write this, it’s 71% on git. I think that’s a testament to the growth from 2016 to now in Git’s popularity.

What would I choose today? Git, hands down, for any project at any company. I might live with the existing system in the short term, but I’d be thinking git, if for no other reason than future hires and staff will likely be more familiar with git than anything else. I’d move in that direction. I don’t know I’d spend time converting existing repositories to git, but if the need arose, I’d be ready to do so.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged , . Bookmark the permalink.

1 Response to Choosing a VCS

  1. paschott says:

    While I lean towards a git-type repo these days for VCS, there are definitely times that a “Check-in / Check-Out” VCS is the better option. That should be considered. I remember working with a team producing content in a structured HTML type style. That included folders, renaming documents, adjusting links, etc. Git did allow for working on branches, but they really needed to check out a whole folder as they restructured everything for some upcoming release. Otherwise the attempt to merge changes was a nightmare. Locking out that structure so they could rearrange everything made it quite clear that those files were off-limits until they were done.

    I appreciate the Git style for a lot of other source control and with a decent process and frequent merges from master into the branch, it works pretty well. You do have to have that discipline of merging frequently, resolving conflicts, adjusting the branch code, and making sure everything is well accounted for. With all of that, I like the structure. I do need to get better about squashing my commits when merging to master, though. I often have a bunch of small work along the way, fixing typos, adjusting code slightly, etc. Nobody needs to see all of that when it boils down to “implemented feature X”. 🙂


Comments are closed.