A version control system enables you to record your changes to the files in a project, effectively building up a history of revisions. Having a complete history of changes in your project enables you to switch back-and-forth between revisions if you need to. For example:

These are the most obvious benefits of keeping the history. However, there is a very powerful hidden benefit too—knowing that you can easily switch back to any previous state liberates your mind from worries that you might break something. Being able to return to any previous state means that you cannot really break anything. Once a revision is recorded in the history, you can always return to that state. Revisions are like snapshots, or milestones that you can return to anytime.

As a consequence, you can go ahead and make even drastic changes with bold confidence. This is a crucial point. This key feature enables you to focus on the real work itself, without the fear of losing anything.

Have you ever made a copy of a file or a directory and added a timestamp to the original one, so that you could make experimental changes? With a version control system, you can stop making copies and avoid getting lost in the sea of timestamped files and directories. You are free to experiment, knowing that you can return to any previous state at any time.

Having a full history of revisions is one thing. It is also important to have a simple way of viewing the history of changes; for example, an overview of what has changed from revision to revision, as follows:

This way, in case you need to retrieve something from a past revision, the log messages help to identify the exact point to jump to in the history. In a version control system, this typically works by entering a brief summary when recording a new revision. Often, the easiest way to find a particular past revision is by reading or searching the log of these summary messages, which should serve as a readable timeline or "changelog" of the project.

Being able to view files at any past state is great, but often what is even more interesting is the difference between two states. With a version control system, it is possible to make comparisons between any two states of specific files, directories, or the entire project. For example, the difference between two revisions of a text file can be displayed as follows:

Let's call the compared revisions base and target. The left-hand side shows the file as it was at the base revision, while the right-hand side is at the target revision. The coloring indicates what has changed, going from the base state to the target state:

However, this kind of a detailed view of the differences is only possible for text files. In case of binary files, such as images, Word, or Excel files, the differences are binary and therefore are not human readable. In case of these and other binary formats, the only way to see the differences is to open both revisions of the file, and to compare them side by side.

Viewing the differences is most useful in projects with mostly plaintext files, such as software source code, system administration scripts, or other plaintext documents.

Being able to revert a project's files to any previous state gives you the freedom to make bold changes. What is even better, though, is if instead of completely undoing a set of experimental changes, you can work on multiple experimental improvements or ideas in parallel and switch between them easily.

Take, for example, a software project that is stable and works well at revision X. After revision X, you can start working on a new feature. As you progress, you can record a few revisions, but the feature is not complete yet. In fact the software is not stable at the moment until you finish the feature. At this point, the revision history may look something similar to the following:

During this time, users use the stable version of the software based on revision X, and discover a serious problem that had been overlooked. Your current version of the project is incomplete, but you must fix the problem urgently and release a new stable version of the software. What can you do?

One solution is to revert to revision X, fix the problem, release the fixed version for the users, restore your work on the new improvement, and continue. While this is possible and the version control system helps by minimizing your effort, this solution is tedious and makes the revision history confusing to follow:

Effectively, we have confined ourselves to a linear history. Although it works, the result is awkward. Also, keep in mind that at some point you will want to reach a state that includes both the completed new improvement and the bugfix you did in revision Y, further confounding the revision history.

A much better and more natural solution is to break the linearity of the history and introduce a new branch, as follows:

That is, instead of reverting your ongoing work on the new feature, create a new branch that is isolated from your current work and fix the problem of the stable version in that branch. A version control system can do this efficiently, using minimal additional disk space in the process.

Now, you have two parallel versions of the project—one that is stable and another that is a work in progress. The version control system makes it easy to switch between the two. You could have even more branches if needed. In reality, it is all too common that your current work must be interrupted for some reason, and branching is a practical solution in many situations. For example:

Our work is interrupted every day. Being able to work on multiple branches and switch between them easily can help a lot, minimizing the impact of interruptions and thereby saving us time and increasing our productivity.

Although being able to work on branches is great, what is even more important is bringing the various branches together, which is called merging. In the preceding examples and in most practical situations, having multiple branches is not the end goal, and most of the time, branches are temporary and short-lived. The end goal is to have all the improvements done on a project, unified in a single place, on a single branch, as follows:

Revision Z is the result of merging the two branches—the stable branch and the branch of the completed new improvement, and it should include all the work done in these branches.

Merging is a complicated and error-prone operation. It is an important job of a version control system to make merging as painless as possible, and intelligently apply the changes that were recorded in the branches you are trying to merge. However, when there are conflicting changes in two branches; for example, one branch modified a file and another branch deleted the same file, then the version control system cannot possibly figure out the right thing to do. In such relatively rare cases, a user must manually resolve the conflict.

Branching and merging does not have to be an advanced operation reserved for power users. A version control system can make this relatively easy and natural. Once you become comfortable with this feature, it will boost your productivity, allowing you to work on multiple ideas in parallel in an organized way. Branching and merging are especially crucial in collaboration. Without branching and merging, it is not possible to work in parallel; collaborators will have to work in lockstep, with only one person recording new revisions at the same time, which can be inefficient and unnatural.

There are many acronyms and names related to version control that can be confusing sometimes, so it's probably worth clarifying them here: