Version Control
Published: 2023-04-19 02:48:44

Many people who start out in coding are always told the same thing: install git, create a github account, learn a few command line prompts, and get hacking. But what is git and github, and why is it that beginner developers are always led down their paths? 

## What are git and github?

Github is a cloud based hosting service that allows users to store and manage their repositories. There are other services like github that are available, each with its own advantages, but they all fundamentally do the same thing. 

Git is a version control system (VCS). It is installed locally on your machine. VCSs are used by developers to, well, control the different versions of their code. Git can be used without a service like github, but it is general practice to use one. Using such a service makes sharing, collaborating, and backup of repositories significantly easier.  

## Why git?

Git was created in 2005 by a Finnish software engineer named Linus Torvalds. At the time, Torvalds was creating the Linux OS with other developers and the VCS they were using (BitKeeper) was no longer going to be free to use, and Torvalds didn't like any of the other VCSs that were available. So he spent a week developing git to use with the Linux project. 

BitKeeper is a type of VCS called a distributed VCS, or DVCS (and it was the original DVCS, although sometimes the credit goes to git), which has many advantages over a centralized VCS, or CVCS, so Torvalds modeled git after it while changing some aspects to better suit his projects' needs. Today, git is by far the most commonly used VCS, some estimates state that [over 90% of developers use it](https://stackoverflow.blog/2023/01/09/beyond-git-the-other-version-control-systems-developers-use/#:~:text=Our%20developer%20survey%20found%2093%25%20of%20developers%20use%20Git.). 

## Types of version control systems 


**Local Version Control System**

Most VCSs fall into one of three categories. The simplest and most error-prone VCS is a local VCS (LVSC). Image you are writing an essay. When you make a change to paragraph 1, you create an entirely new copy on the essay. Then later on you make a change to paragraph 2, and again create a new copy of the essay. When it comes time to put your essay together to give to your teacher, you will have to read the different copies you have created and combine them into one final copy. Developers can do a similar thing with their code; create a new folder each time they edit the code to keep track of their changes over time. This might work for a very small, single-person project, however a LVCS does not scale well and can lead to many bugs in the code. 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jzecnpgpywgeyo6apjh3.png)

**Centralized Version Control System**

Another type of VCS is a centralized VCS, or CVCS. In this system the 'master copy' (called the single source of truth, or SSOT) of the code is kept in a remote server. Anyone who wants to edit the code will have to get a copy of it, make their changes, then push them back up to the SSOT. CVCSs are not without issue. When developers are working on the code, they must have access to the remote server to 'checkout' the SSOT and to push up their changes. The process of 'checking out' the SSOT does not create a copy to the developers local machine, meaning that all code is only stored in a remote server. Assuming that their are no backups of that remote server, if something happens to server the developers are at risk of losing their entire code base. In addition, when multiple developers are pushing their changes into a SSOT, code conflicts that arrive are often dealt with by hand. CVSCs offer many benefits over LVCSs. They used to be the industy standard, and are still used by some today, but with the rise of distributed VCSs they have fallen out of popularity. 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ffeo08rog9oudqhadl57.png)

**Distributed Version Control System**

The final VCS is the distributed VCS, or DVCS, which is what git is. To best explain the way it works, imagine a CVSC. But when a developer 'checks out' the SSOT, the entire project gets copied to their local machine. Now they are free to work on it and make commits with or without access to the remote server. Git is incredibly popular due to a feature it provides relating to the codes history. Every time a developer makes a commit, a corresponding hash (a 40 character hexadecimal string) is created that represents the changes that were made to the file. The SSOT will always have a well-documented history because of this feature. Even if something were to happen and the SSOT was lost, the process of creating a local copy on a developers machine gives it access to the entire project's history, meaning that all the code and its history is preserved (of course, only through the last time the developer updated their local copy to be current with the SSOT). Not all DVCSs offer this unique history feature, but it is worth discussion. Another benefit of DVCSs is their ability to branch. If a developer wanted to work on just one part of their project but don't want to work on the SSOT, they can create another branch to do so without potentially harming the SSOT. When their changes are ready to be put into the SSOT, any code conflicts are handled through a service like github's GUI. However, the use of branching typically does result in less code conflicts. The major drawback of a DVCS is that developers may rely too much on their local copy. Without frequently pushing up their code and pulling down any new changes to the SSOT, over time they can be working on code that may no longer be compatible with the SSOT. Git has it's own draback, too. The inital creation of a local copy might be time consuming if the project has a large history. 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l1t4qztiil3xwrmxchxl.png)