Why Use a Version Control System?

 Why Use a Version Control System?

What is Version Control?

We can consider a version system (short: “VCS”) as a sort of “database”. It lets us save a snapshot of our complete project at any time we want. once we later take a glance at an older snapshot (let‘s start calling it“version”), our VCS shows us exactly how it differed from the previous one. Version control is independent of the type of project/technology/framework we‘re working with: It works even as well for an HTML website because it does for a design project or an iPhone app. It lets us work with any tool we like; it doesn‘t care what quite a text editor, graphics program, file manager, or another tool we use. Also, don‘t confuse a VCS with a backup or a deployment system. We don‘t need to change or replace the other part of our toolchain once you start using version control. A version system records the changes we make to our project‘s files. this is often what version control is about. It‘s really as simple because it sounds.

Why Use a Version Control System?

There are many benefits of employing a version system for our projects.

Collaboration

Without a VCS in situ, we‘re probably working together during a shared folder on the same set of files. Shouting through the office that we are currently working on file “xyz” which, meanwhile, our teammates should keep their fingers off is not a suitable workflow. It‘s extremely error-prone as we‘re essentially doing heart surgery all the time: sooner or later, someone will overwrite someone else‘s changes. With a VCS, everybody on the team is in a position to figure absolutely freely – on any file at any time. The VCS will later allow us to merge all the changes into a standard version. There‘s no doubt where the newest version of a file or the entire project is. It‘s during a common, central place: our version systemOther benefits of employing a VCS are even independent of working during a team or on our own.

Storing Versions (Properly)

Saving a version of our project after making changes is an important habit. But without a VCS, this becomes tedious and confusing very quickly: 

  • How much does one save? Only the changed files or the entire project? within the first case, we’ll have a tough time viewing the entire project at any point in time – within the latter case, we‘ll have huge amounts of unnecessary data lying on our disk drive
  • How does one name these versions? If we‘re a really organized person, we’d be ready to stick with an actually comprehendible naming scheme (if we‘re proud of “acme-inc-redesign_2013-11-12_v23”). However, as soon because it involves variants (say, we’d like to organize one version with the header area and one without it), the likelihood is that good we‘ll eventually lose track. the foremost important question, however, is perhaps this one: 
  • How does one know what exactly is different in these versions? only a few people actually take the time to carefully document each important change and include this in a README enter the project folder. A versioning system acknowledges that there’s just one project. Therefore, there‘s just one version on our disk that we‘re currently performing on. Everything else – all the past versions and variants – is neatly packed up inside the VCS. once we need it, we will request any version at any time and we‘ll have a snapshot of the entire project right at hand.

Restoring Previous Versions

Being able to revive older versions of a file (or even the entire project) effectively means one thing: we can‘t mess up! If the changes we‘ve made lately convince be garbage, we will simply undo them during a few clicks. Knowing this could make us tons more relaxed when performing on important bits of a project.

Understanding What Happened

Every time we save a replacement version of our project, our VCS requires us to supply a brief description of what was changed. Additionally (if it‘s a code/text file), we will see what exactly was changed within the file‘s content. This helps us understand how our project evolved between versions.

Backup

A side-effect of employing a distributed VCS like Git is that it can act as a backup; every team member features a full-blown repository of the project on his disk – including the project’s complete history. Should our beloved central server break down (and our backup drives fail), all we need for recovery is one among our teammates’ local Git repository.

Leave a Comment