An introduction to Version Control

I first heard about Version Control (VC) in my first year of programming class and didn’t care much for it. I had a project that required the use of it so i scratched the surface and let it go as soon as i was done with the project.

Couple months down the line i learnt the benefits of it the hard way. The night before a presentation, I was knee deep in a group project we had been working on for a java class. 3 different computers, 3 different sets of code with 3 different sets of working modules.

Great example of my confusion fusing two versions of code

What was the problem? We couldn’t integrate the project into one whole solid running application. Saving files as “project_version_{insert_date}” didn’t help me here. With every attempted integration, we had more bugs and more bugs, finally we gave up at 6AM just a couple hours before our presentation which by the way we failed miserably. We failed not because we didn’t have a working software, we failed because we didn’t collaborate effectively.

The common misconception is that by definition, VC is github, or bitbucket. Trust me it’s quite easy to make that mistake considering that they are built to use VC, however, when we take a closer look you find that although they do help, which you will read about a few lines down, they are only part of the definition. VC in simple terms is something I like to think of as a database, I can make changes to the data whenever i want, I can also allow others to make changes too. I can also see a trail of all the changes i have made. So in a sense i can see all my old “project_version_{insert_date}”. VC allows a group of people to work on a project and not step on other people’s toes. In some situations, it bridges gaps and allows developers in remote areas collaborate on projects.

A main or master version is maintained and team members are allowed to make changes on their local versions until they are ready to commit to the master. Options to lock files and resolve conflicts are available. If we had used version control in our project, 3 computers with 3 different sets of code would have been a walk in the park, we wouldn’t have lost an ounce of sleep.

There are a few VCS available on the market, these include Git, Microsoft Team Foundation Server, Subversion, Mercurial and so many more. Differences between VCS systems aren’t many but the important ones mostly lie in the architecture, they can either be server based or peer to peer. Examples of software making use of VCS include GitHub and Bitbucket. Github is one of the most popular used by over 20 million users with over 40 million repositories as at April 2017.

Choosing a platform is usually down to preference. I have used Git more and find that i enjoy saying git, that’s why i use it. As a consequence, I use GitHub a lot too. Though, it’s worth mention Bitbucket works too, as well as GitLab, Kiln, Beanstalk and so many others. Google also has its own platform called Cloud Source based on Git just like Amazon’s platform AWS Code Commit. Other metrics to consider when selecting your platform include speed, functionality as well learning curve. Always best to look up a framework or system and read what other developers think about it and why they would use it.

Should you use VC? Of course you should. The question really is which one best suits your needs. In the next article, we’ll delve into the different version control systems and their pros and cons..

www.agoracode.community