Version control is a system that lets you manage changes to files and projects. It is considered by many to be the backbone of professional software development due to its daily use by developers. Thus, understanding what it is, how to use it, and common terminology associated with its use is fundamental in the success of any developer. 

Version control has several names and is also called source control or source control management. It's also occasionally referred to as “revision control,” although the term is rarely used. Instead, you will predominantly hear it called “source control” and “version control.” The three main components of version control systems include the following:

1.    A safety net for restoring saved work. Within version control, saving is foolproof. The program provides a safety net allowing you to restore work to a previously saved state. This means you can incrementally build your work knowing you've saved a safe copy at each stage of development. This will effectively let you travel back in time if needed to revert back to a previous copy. For instance, if you notice an error several versions back, you can move back in time to the snapshot before the one with the error, and that will lose the bug from the snapshot with the error and the changes from your newest snapshot. Alternatively, you could discard the snapshot with the error and merge the changes from your newest snapshot. In contrast, if you notice a problem in a snapshot in which you are currently working, rolling back changes only requires resetting the latest snapshot. Then you can restore the files to exactly how they were just before you saved, or you can reset everything to your latest save point discarding all changes that happened after that. Version control gives you the nuance you need to restore or discard work exactly how you need to. 

2.    Collaboration. Version control lets you coordinate changes in a large group, allowing you to work independently but with many people on the same project at once to create a polished final result. Not only can you pick and choose changes from your coworkers or teammates and decide exactly how you want to update your project, but you can also propose different implementations of the same feature.

3.    Trying ideas before adding them to a project. Version control lets you create branches to develop new features and fix bugs without putting your main project in danger. This means you can test new ideas before committing to them and create safe alternative versions of your project to work from. Additionally, this allows coworkers or team members to provide feedback and design critiques. Once you finish developing and testing your new features or fixes, you can safely merge the changes from your branch back to the master. 

With these three key features, users and teams can optimize their version control experience and easily manage changes to files and projects. Now let’s explore the type of version control language you will need to familiarize yourself with as a developer. Below are ten core version control concepts to get you comfortable. 

1. Git. The most common version control system for most development projects is Git, and the most common place to use Git is either directly on a computer or at github.com. Still, you may wonder how to use Git. Like all version control, Git lets you save incremental versions of your work so you can review changes over time.  

2. Repo. Each Git project is called a repository, or “repo” for short. A repo stores all the files and changes made to your project. It’s like a project with memory allowing you to move back and forward in time and observe the ways you have changed and modified your project. Thus, the repo stores data and change information. For developers it can be especially useful as they are learning version control systems to practice how to clone a GitHub repository and know how to delete a repository in GitHub. 

3. Commit. The three big things you do with version control are commit, clone, and branch. When you commit a change, you add your latest changes to your repo and are directing information to be filed. As in life, commitment is a serious responsibility – and is why every commit needs a serious commit message. A commit message explains changes and is the primary way to communicate changes to your development team. When you commit, you push your changes to the repository, and all information heading upstream to your repo is pushed. This push propels information from your local source into the shared repository. 

4. Diffs. Every time you commit there are differences between the project from the last save point to the new one. These changes are called differences, or “diffs” for short. You can compare changes between commits by looking at the diffs.  

5. Conflict. A conflict occurs when two parties change the same file and there's no automatic way to reconcile the changes. You must resolve the change by selecting which change wins.

6. Clone. When you clone a Git repository, you create a local copy to work on and your version will match the contents of the repository at the time you cloned it. For instance, you can clone a repository on GitHub to your computer where you can compile it from source, modify it, and more. 

7. Pull. If you've been working on a clone project, you may need to catch up with changes others have made by pulling, which changes revisions from the repository to your local copy.  

8. Forking. Another way to copy a repository is called “forking,” and is more like a fork in a tree. Unlike when you clone and make a copy on your computer, forking involves making a new repository, typically on GitHub or whatever hosting site you're using. A fork has all the contents of the original, but you are now the owner of this new repository and you're starting a new development project. You're copying a project when you fork and you're working on a project when you clone. 

9. Branch. Branches let you create alternate versions of your project. When you branch you can work on new features and try new ideas without messing with your main work. Consider this – your main work may have many names and, like a tree trunk, it’s commonly called the “master,” “master branch,” or “baseline.” The trunk or master is where your team keeps its primary project development and if it’s messed with, your team will suffer. Thus, if you plan to work on something that will take a while and may break your build, be sure to branch so you don't interfere with the work of others on your team. 

10. Check out. Similar to cloning a repository, checking out a branch lets you move from branch to branch, making sure you're only working on the parts of projects that you intend to. 

Now that you know the basic vocabulary and key features of version control, you are ready to hit the ground running as a new developer. Don’t forget to commit!

For more information on understanding version control, watch our version control video tutorial. For more information about the basics of version control vocabulary, watch our version control vocabulary overview.