Chapter 1: Git and VCS

Different versions of project tracked using Git as a VCS

This is the very first part of our Git series. We are going to cover following chapters.

1. Chapter 1: Git and VCS
2. Chapter 2: Visual Introduction to Git: Creating Cars 🚓 on Gitland = Workshop → Magical Truck →Storehouse
3. Chapter 3: Practically Using Git: Creating Cars 🚓 on Git = Working Directory → Staging Area → Repository
4. Chapter 4: The General pattern for using Git: A pattern or template for using Git in Day-to-Day life

In a nutshell, Git is software that helps you track changes in your project, easily roll back (go back) to a previous version if things go wrong and so much more as we learn through this series. We can use Git both as a command-line tool (CLI) or Graphical User Interface (GUI). We will mostly use CLI as it will help you learn essential concepts and it's easily available for every platform, but use GUI when it's appropriate. After all, it's necessary to use the right tool for the right job.

To set the objectives clear, both for you, and me, below are the guidelines that I will follow and expect you to follow.

Guideline

1. You don’t need to be an expert in Git, neither I am. We don’t need to be an expert to use this amazing tool once you learn the concepts.
2. This whole series will include only those things that I have personally used in my projects. Thus it will help you quickly add Git to your toolbelt instead of sticking on some feature that is rarely used.
3. You should follow the 80–20 rule i.e 80% of the time you will use 20% features of Git, which is more than enough to get you started.
4. Focus on concepts rather than learning commands and syntax.
5. I will follow the metaphor style while explaining certain concepts, which will help in retaining the concepts for a lifetime. Especially to explaining certain terms like “checkout”, “forking” etc.
6. Break complex jargon commonly used in Git in simple words like a repository, snapshot, merge, rebase, etc.

Motivation

Nowadays rich text editors like Microsoft Word, Google docs, Medium.com, etc have built-in Git-like software that helps users automatically save different versions of the same document. However such features were not present earlier, or even today, source code editors like Notepad, Sublime, Visual Studio, etc don’t offer such built-in tools, not because they can’t, but because tracking a source code is different, than automatically saving multiple versions of a file.

You might have done something like this. For example in a resume folder put all the versions of your resume.

multiple versions of resumes inside 1 folder

Or something like this to manage different versions of your software project.

multiple versions of the todo-app inside 1 folder

Using the first approach is fine if you have to track only a single file, but it becomes really complicated and error-prone when you have multiple files in your project. If you use Git, then you can get rid of all such headaches and simply let Git intelligently manage all versions of your software. Moving back and forth is as simple as...

$ git checkout v1  // takes to version 1 of our project
$ git checkout v3  // moves back to latest version 3 of our project

Git for everybody

Everyone (including non-tech people) should at least know and admire the power of Git. It doesn’t matter what OS you use, language or IDE, framework, domain, programming experience, or the size of team you work with. Everybody can benefit from Git. It will change the way you produce/author software.
I have really struggled, in learning Git, though we have an abundance of information on the internet about Git, still, it took really long time for me to actually learn Git to be useful in professional projects, where you need concepts rather than copy-pasting commands from StackOverflow. I will try my best, to teach you the concepts instead of being another copy-paste source.

The Deeper The Roots, The Greater The Fruits

Git

Git is the most popular distributed Version Control System(VCS) in use. Today almost all new projects choose Git over other VCS, because of its simplicity, and its market share. According to openhub.net which tracks around ~500K open-source projects, almost 75% of projects use Git as their VCS.

Git’s market share source: https://www.openhub.net/repositories/compare

Version Control System(VCS)

To understand Git, we should first understand what a Version Control system (VCS) is since Git is one among other VCS available in the market.
A Version Control System (VCS) is software or an application in your system which stores/tracks the complete history of your software project. It does this by smartly storing multiple versions of a project on behalf of you. A typical VCS like Git offers the following eye-catching benefits

Benefits of using VCS like Git

1. Move back and forth between multiple versions without losing any piece of code.
2. Compare difference (code added/removed) between any 2 versions of a project.
3. Roll back to a previous version if things go wrong.
4. Deploy multiple versions of software. It’s very common to have production, staging, development versions of the software hosted at the same time.
5. Allow multiple collaborators(team members) to work simultaneously on different features and merge those features back into a single unit.
6. See the entire history of the project i.e new features, bug fixes, etc. in a single glance (Git logs)
7. Experiment with new features, without worrying about breaking existing working software, by using the Git Branching model.
8. Review changes before committing (git diff)
9. Know exactly who has introduced a certain piece of code, very useful for blaming someone for bugs (git blame)
10. Backup entire repository (all versions) of software using remotes (dropbox/drive like system for git projects) like Github
11. Trigger automatic actions on new versions of software (Github Actions).
12. And many many more….

There are 2 kinds of VCS available in the market namely

1. Centralized VCS
2. Decentralized VCS

It is good to understand the distinction between a centralized and decentralized VCS since Git is a decentralized VCS, and it will help us understand the different features of Git.

Centralized Vs Decentralized VCS

Centralized VCS

These were the first kind of VCS introduced in the ’70s. In a centralized VCS, the project’s repository is stored on a central server and all other collaborators must connect through a network (internet) to collaborate(work) on a project. It was a good model for those days where a small set of people used to work on a project using terminals (display and keyboard) and connecting to a main-frame computer.

Centralized VCS

As you can see, the repository (version database) is stored on a central server. If let us say User A wants to collaborate using Computer A, he will need to pull files from the central server, edit them, and push changes back to the central server. Similarly, User B has to go through the network to do something.

Pros:

1. The user doesn’t need to store the complete repository on his local machine, thus saving a lot of space and memory.
2. Everybody knows what others are working on since every change finally goes to a central server.

Cons:

1. Single point of failure, if the central server crashes or goes down, none of the collaborators will be able to work.
2. Users must be connected to the network to do anything (forget working from home, those days with low internet connectivity).
3. All operations are slower since everything will have a network latency.
4. Code can be lost, if not pushed to a central server, since the Central server is the final source of truth.

Decentralized VCS

In a decentralized VCS, every participating computer i.e both the central server and participating user’s computers store the complete repository of a project. Yes, users need a network connection to share changes, but, they can make local changes, without being connected. This improves development time massively, as one can contribute even living in a remote place.

Decentralized VCS

As you can see both central and user’s computer A and B store the complete repository, thus having access to all versions of the project. To collaborate (share changes) users will push changes to a central server and other users can pull changes from the central server to their computers.

Pros:

1. Users can collaborate without always being connected to the internet.
2. No single point of failure, as almost all code is available with all users at all times.
3. Operations are local (executed on users' machine) thus zero network latency for performing basic VCS operations like checking out, committing, etc.
4. Easily navigate back and forth between versions, almost instantaneously, since all versions are stored locally.

Cons:

1. Users need to store the entire repository, thus it can take more memory space on the user's machine (however VCS like Git, intelligently stores the changes which reduce the size of the repository massively, no need to worry about exhausting your storage)
2. If the user is not pushing changes frequently to the central server, then other users will not be able to see what work is happening in the project.

After comparing both Centralized and Decentralized VCS we can conclude that Centralized VCS were important in those eras when a limited number of people used to work on software projects and had access to the internet when the rate of storage/GB was high and people used to work only from office.
In recent decades rate of storage/GB has become cheap, access to the internet is available to common people, many people are contributing to software projects, and Work from Home has become a norm. All of these factors make Decentralized VCS the need of time and most companies prefer using Decentralized VCS like Git.
This doesn’t mean Centralized VCS has become absolute, people still use it, but this mostly, because they or their company is reluctant to accept new technology. As a beginner you should learn Git as almost every new project in your company will use Git to track the source code.

This was just a technical introduction to Git, in the next chapter we are going to learn the different components that make Git so awesome. Be excited to create your own car.

References

1. Git Book
2. Git Tutorial for Beginners: Learn Git in 1 Hour by Mosh Programming with Mosh