You should be using GIT
If you’ve been using source control, but haven’t made the change to git yet, let me try to convince you. I first heard about git a few years ago. It sounded interesting at the time, but my source control was working fine (or so I thought), so I didn’t pay too much attention. Around 4yrs ago, I started a new project and had to pick a source control system. One of the options we tried out was git. Like most people, I searched google, read a bit of the docs, then hopped into the command line. It was a disaster….
I’ve used command lines since the C64 days, can easily handle dos, powershell, and USED to be good with with linux. That said, I’ve been primarily developing on windows, building games, websites and apps since the 90’s. Using git via the command line felt un-intuitive and confusing. Combining that with a new set of definitions for commands made it more confusing. All this combined into the perfect storm of confusion.
Around 2 years ago I attended a few “Intro to Git” talks that explained the basics. They always covered how git works and how to get around the command line. They’d occasionally touch on the fact that visual tools existed, but they’d focus on the command line because people who love git enough to do talks on it, love command lines.
The first thing I want to say if you’ve been avoiding git because it seems complicated/confusing, ignore the command line. You can learn to use it later. For now, grab one of the good graphical tools and get a bit of experience with git. My preferred git tool is SourceTree.
Graphical tools have existed for every other source control system, so you may still need some more convincing. The typical git pitch mentions things like offline commits & easy branching. I won’t be covering those today. Instead, I’ll focus on 4 points where git excels which I think may be more convincing.
#1. No file locking / read-only files
This may not be an issue for everyone, but if you’ve been a long time perforce user then you’ve fought with read-only files. If you also happen to use Unity3D, you’ve realized just how terrible it can be. With git, your files will no-longer be locked, read-only, or need to be checked out before you can work.
#2. Partial file commits
This one alone may be enough to convert some people. Before switching to git, I can’t count the # of times where I was working on a feature, but needed to make a quick minor fix. Before git, I’d stash my changes to the file in question, make the fix, and hope everything still built. Then I’d commit, un-stash, and hope I didn’t mess up my previous work.
Git offers the perfect solution to this. Partial commits. If you’re using source tree, you can see just how easy it is in the image below. 
It will find the different areas of your file that have changed, and you just choose the part(s) you want to stage for commit. You can simply commit what you want, and leave out everything else you’ve been working on.
#3. Commit changes without pushing them
You can commit, without pushing out your changes to anyone else. If you’re still working on a feature, not sure about your code, or you’re just afraid to break an upcoming release, you can still commit. Until you PUSH, your code is only committed locally. You can roll back your changes, modify them, etc, without anyone else having access to the code until you’re ready. It’s liberating…
#4. Finding changes is EASY
I can’t speak for all version control systems, but in many, finding your changes can be a pain. Some systems like P4 require you or a plugin to specify each file (there are ways to find them, but they’re a pain too). With git, it looks at the file system and sees your changes every time. In the graphical tools, you get a nice easy view of all your changed files where you can choose which ones (or parts) to stage for commit.
There are of course many other reasons to use git. It’s taken over as the primary source control system because it’s better than the competition. I’m happy to have made the switch, and can’t imagine ever going back. I hope I’ve convinced you as well.