In this blog post, we'll be outlining a number of key terms that everyone should know when using a version control system in your development workflow.
Repository
A repository is where all files and directories are stored. This includes all historic revisions, including all patches and metadata. With distributed version control systems, there may not be a central repository as it can just be located on your local computer instead.
Checkins and Tracking
Essentially, all version control systems boil down to checking in a file and recording the changes that are made. In traditional, centralised version control systems such as Subversion, this is called ‘checkin’. When a programmer makes a change to a file, the changes are reflected in the repository and will become available instantly to other developers once they run an update.
Whilst a distributed version control system is very similar to this process, files need to be tracked first in order to be recorded within its system. Afterwards, you can make changes to this file and perform a commit every time you want to record a new revision.
As an added bonus, in distributed version control systems such as Git, files may have small, specific changes made to them by staging them first which then allows you to commit parts or all of the changes you've made.
Diffs
The repository will contain all version history of a file as it evolves and diffs are the actual changes you made whilst editing. To help reduce storage space, many version control systems only store changesets (changes in files) rather than full copies of a file.
Diffs are a helpful way of identifying differences between changes on a file. You can also apply these changes to other branches.
Branching
Branching is a very useful feature in version control systems. It allows you to branch out and diverge from the main line of development and allows you to continue developing without affecting the main (or master) branch.
Traditional centralised version control systems (such as Subversion) will duplicate the main project (trunk) into a separate folder so you may continue your development. Whereas with modern distributed version control systems (such as Git), branching is very lightweight, which makes it easy and simple to switch back and forth between branches.
Merging
At some stage in your development you will want to merge your branch back into master. Merging is a fundamental operation to reconcile multiple changes which results in a single collection of files containing both sets of changes.
Typically this process is performed automatically by the version control software if there is sufficient history to reconstruct changes and the changes do not conflict. In certain situations, someone may need to manually merge changes and make decisions as to which changes should be contained in the resulting files. Most revision control software provides various tools to include merge capabilities.
Conflicts
Merging can be performed automatically but there are situations when changes conflict. When changes overlap or contradict each other, someone will need to manually resolve them before you can commit any further changes.
Tagging
When you come to a successful point in your project, you may want to apply a meaningful label for posterity reasons. Tagging is technically a static snapshot of your repository at that particular moment in time. It’s typically used to tag releases, such as a version 1.0 release.
Further Reading
If you're still hungry for more, have a look at my introduction to version control post, or check out these beginner-friendly Git guides on the DeployHQ website.
Summary
These were just a few of the most common terms found in version control systems, we will be going through them in more detail in future posts in this series. Otherwise, you can get in touch with us at any time if you have any questions.
