You can think of the version control system as a kind of "database". It lets you save a snapshot of your complete project at any time you want. When you later take a look at an older snapshot (let's start calling it "version"), your VCS shows you exactly how it differed from the previous one or the current version.
Version control is independent of the kind of project / technology / framework you're working with. It works just as well for an HTML website as it does for a design project or an iPhone app. It lets you work with any tool you like; it doesn't care what kind of text editor, graphics program, file manager or other tool you use. Also, do not confuse a VCS with a backup or a deployment system. You don't have to change or replace any other part of your tool chain when you start using version control. A version control system records the changes you make to your project's files.
There are many benefits of using a version control system for your projects. This chapter explains some of them in detail.
Collaboration
Without a VCS in place, you're probably working together in a shared folder on the same set of files. Shouting through the office that you are currently working on file "xyz" and that meanwhile, your teammates should keep their fingers off, is not an acceptable workflow. It's extremely error-prone as you're essentially doing open-heart surgery all the time: sooner or later, someone will overwrite someone else's changes.
With a VCS, everybody on the team is able to work absolutely freely - on any file at any time. The VCS will later allow you to merge all the changes into a common version. There's no question where the latest version of a file or the whole project is. It's in a common, central place: your version control system.
The other benefit of using VCS is, independence while working in a team or on your own.
Storing Versions (Properly)
Saving a version of your project after making changes is an essential habit. But without a VCS, this becomes tedious and confusing very quickly.
How much do you save? Only the changed files or the complete project? In the first case, you'll have a hard time viewing the complete project at any point in time - in the latter case, you'll have huge amounts of unnecessary data lying on your hard drive.
How do you name these versions? If you're a very organized person, you might be able to stick to an actually comprehensible naming scheme (if you're happy with "acme-inc-redesign-2013-11-12-v23"). However, as soon as it comes to variants (say, you need to prepare one version with the header area and one without it), chances are good you'll eventually lose track.
The most important question, however, is probably this one: How do you know what exactly is different in these versions? Very few people actually take the time to carefully document each important change and include this in a README file in the project folder.
A version control system acknowledges that there is only one project. Therefore, there's just the one version on your disk that you're currently working on. Everything else - all the past versions and variants - are neatly packed up inside the VCS. When you need it, you can request any version at any time and you'll have a snapshot of the complete project right at hand.
Restoring Previous Versions
Being able to restore older versions of a file (or even the whole project) effectively means one thing: you can't mess up! If the changes you've made lately prove to be garbage, you can simply undo them in a few clicks. Knowing this should make you a lot more relaxed when working on important bits of a project.
Understanding What Happened
Every time you save a new version of your project, your VCS requires you to provide a short description of what was changed. Additionally (if it's a code / text file), you can see what exactly was changed in the file's content. This helps you understand how your project evolved between versions.
Backup
A side-effect of using a distributed VCS like GIT is that it can act as a backup; every team member has a full-blown version of the project on his disk - including the project's complete history. Should your beloved central server break down (and your backup drives fail), all you need for recovery is one of your teammates' local GIT repository.
Although there are dozens of version control systems on the market, some of the world's most renowned projects (like the Linux Kernel, Ruby on Rails, or jQuery) are using GIT as their VCS of choice. Here are some of the reasons why.
Save Time
GIT is lightning fast. And although we're talking about only a few seconds per command, it quickly adds up in your work day. Use your time for something more useful than waiting for your version control system to get back to you.
Work Offline
What if you want to work while you're on the move? With a centralized VCS like Subversion or CVS, you're stranded if you're not connected to the central repository. With GIT, almost everything is possible simply on your local machine: make a commit, browse your project's complete history, merge or create branches – GIT let's you decide when and where you want to work.
Undo Mistakes
People make mistakes. A good thing about GIT is that there's a little "undo" command for almost every situation. Correct your last commit because you forgot to include that small change. Revert a whole commit because that feature isn't necessary, anymore. And when the going gets tough you can even restore disappeared commits with the Reflog - because, behind the scenes, GIT rarely deletes something. This is peace of mind.
Don't Worry
GIT gives you the confidence that you can't screw things up - and this is a great feeling. In GIT, every clone of a project that one of your teammates might have on his local computer is a fully usable backup. Additionally, almost every action in GIT only adds data (deleting is very rare). That means that losing data or breaking a repository beyond repair is really hard to do.
Make Useful Commits
A commit is only really useful if it just contains related changes. Imagine having a commit that contains something from feature A, a little bit of feature B, and bugfix C. This is hard to understand for your teammates and can't be rolled back easily if some of the code is causing problems. GIT helps you create granular commits with its unique "staging area" concept: you can determine exactly which changes shall be included in your next commits, even down to single lines. This is where version control starts to be useful.
Work in Your Own Way
When working with GIT you can use your very own workflow. One that feels good for you. You don’t have to be a code acrobat to qualify for using GIT. Of course, you can connect with multiple remote repositories, rebase instead of merge, and work with submodules when you need it. But you can just as easily work with one central remote repository like in Subversion. All the other advantages remain – regardless of your workflow.
Don’t Mix Things Up
Separation of concerns is paramount to keeping track of things. While you’re working on feature A, nothing (and no one) else should be affected by your unfinished code. What if it turns out the feature isn’t necessary anymore? Or if, after 10 commits, you notice that you took a completely wrong approach? Branching is the answer for these problems. And while other version control systems also know branches, GIT is the first one to make it work as it should: fast & easy.
Go With the Flow
Git is used by more and more well-known companies and Open Source projects: Ruby On Rails, jQuery, Perl, Debian, the Linux Kernel and many more.
A large community often is an advantage by itself because an ecosystem evolves around the system. Lots of tutorials, tools, and services make GIT even more attractive.
