Saturday, May 23, 2020

Welcome to the second post in Git for DBAs series which is Discovering Version Control Systems.In this post we will start talking about the definition of version control and why it is important, also we will give a quick brief about types of version control systems and the advantages/disadvantages of each type.What is Version Control?As a definition and as we can see from any online resources interested in version control, it is simply a system that records changes to a file or group of files over time and based on that we can recall any specific version of these files at any point of time.

What can Version Control do for us?It is a paradigm shift !!, let us imagine what we can do to manage changes we are doing in a project with set of code files and by time we keep changing the code inside those files, what is the traditional approach we will use? ... the answer is easy: keep creating sub-files with different timestamp and names like: my_file_02022018.txt or my_file_last_update.txt ... etc.One of the core added values of version control is that you can have all changes applied on this single file while having a single version of this file and avoid all confusion and mistakes that can happen based on having this big number of multi-versions of this file. Actually, there are much more actions against this file and any other files being tracked by version control:

Moving backward and forward in the changes "versions" of this file like a time machine.

Comparing code changes between those versions.

Reverting files or project "set of files" into a previous state, for example to a specific stable version.

Check who modified files and when.

Check who introduced new code and new issues "this will be explained into more details when we start discussing code collaboration with Git".

Types of Version Control SystemsVersion control systems can fall into three main types:

Local Version Control Systems.

Centralized or Client-server Version Control Systems (CVCSs).

Distributed Version Control Systems (DVCSs).

Local Version Control SystemAs illustrated above, the idea of having multiple versions of the same single file is the core idea of version control which is a local version control which means that it is being applied only on local computer.

However, with local version control we still miss an important benefit, which is collaboration, this is under the fact that we are limited to the scope of local machine for managing our file's changes, then it is still impossible to share our code files with others, and here the client-server version control or centralized version control step in.

Centralized Version Control System (CVCS)

In order to achieve the collaboration goal, then there is a need to have a single location to have all files accessible and maintainable among all collaborators like software engineers, this location is a centralized version control server that contains all these files along with its versions and client machines can connect to this centralized server and get/modify those files.

With centralized version control systems, we are now able to share our code among all collaborators who copy required files into their machines, apply required modifications then push these modifications back to the centralized server.This is a good approach and can be managed by set of permissions that CVCS system administrators can easily apply, however there some downsizes for such systems:

Single point of failure: so in case the CVCS server down then no one can access the different project's code files.

Connectivity: developers or collaborators have to be always connected to this centralized server, which means no offline work can be done at anytime.

Losing history: in case of HW or disk failure for the centralized server with no proper up-to-date backup, then all the projects history will be lost forever.

Distributed Version Control System (DVCS)

Here comes the idea of making the code files with its versions distributed instead of being centralized.In DVCS clients clone a full copy of all code files with versions for the master server into their local machines and then can apply all required modifications locally and when needed they can push those modifications back, by applying this approach we managed to solve all the above downsizes:

Single point of failure: in case the master server dies, collaborators can still work normally on their local copy of code "local repository".

Connectivity: there is no need now to be connected to the master server, as changes can be applied on collaborators local machines, connectivity will be required only when code need to be cloned from master or pushed back to master.

Losing history: by having a full copy of code files cloned on all collaborator's machines, it is not possible to lose our code even there is no backup or the backup is outdated "please note that this is not considered as a backup replacement, backup is always important".

It is also important to mention that distributed version control systems can act as local version control ones too, this will be explained into more details when we start demonstrating how to work with Git as an example for DVCS.

Starting from the next post, we will start our journey with Git and explain its structure, how it works and provide many practical examples and cases.