Chapter 2: Visual Introduction to Git

Creating Cars 🚓 on Gitland = Workshop → Magical Truck →Storehouse

Agenda

1. Understand what responsibility, Git, takes on your behalf.
2. An analogy to remember, Git’s Workflow.
3. After completing this chapter you will understand the core concepts of Git which will help you to follow the third chapter with much more confidence.

All versions of cars we track in our Git’s repository by the end of this chapter

Git’s Responsibility

As we learned in the first chapter that Git is a Version Control System (VCS) or a Source Code Manager (SCM). Like any other VCS, Git takes 2 responsibilities on your behalf.

Git’s Responsibility on your behalf

1. Storage of Version Database
   The most important work of Git is, to permanently store “all the versions” of your software. This gives confidence, to the software engineer, that even if something breaks, while working on a new feature, he will be able to go back to any previous version.
2. Next Version Preparation
   Git helps software engineers, to choose one version from its version database and enhance that version, to make a better new version. Eventually, this new version, once ready, will be stored permanently in Git’s Version Database.

Preparation of the “next version” is again divided into 2 parts. This is done to isolate(separate) the “work in progress” and the “next version”. It’s quite likely that you end up working on some extra pieces, but you only want a subset of changes to be the “next version” and keep other things as “work in progress”.

For managing these responsibilities Git uses 3 sections. Understanding these sections is important, because every git command, somehow operates on these sections. However, learning these concepts is like a “chicken and egg” situation. You need to work with Git for some time before you understand these concepts, on the other hand, you need to understand these concepts before you work. Therefore, I will recommend you, reading the meanings of these concepts and go through the analogy presented below. After reading the analogy, you will understand what I am talking about. These sections are as follows…

1. Repository
   This handles “Storage of Version Database”. In very simple words, it permanently stores every version, you ask Git to save(commit).
2. Staging Area
   Primarily it's responsible to isolate(separate) “work in progress code” and code that is about to become the “next version” of your software.
3. Working Directory
   Handles “work in progress”. You as a developer, checkout(bring) a version from the repository to make it better. The area, where a version is brought, is called the working directory. As a rule of thumb, your project folder is the working directory. The content inside this folder will contain the checked-out version of your project from the repository.

Let me explain these three concepts with an analogy and a story.

Story Time

Once upon a time, there lived a car-maker named “Ram”. Early in his life, his dad trained him, to make cars in a special land called “GitLand”. Initially using GitLand was alien to him, but as he worked and realized from his mistakes and client’s changing requirements, he now uses GitLand to make all of his new projects.

One day a client came to Ram and asked him to make a new car, gave him all specifications, and told Ram to keep him in a loop as he makes the car. Ram took the project.

Day 1:

Ram goes into the GitLand. Before he starts the project, he first creates those 3 sections which will help him in those situations when things go wrong. Just like ants collect food before the rain. You know, precautions are better than cure. His dad thought him a special Git Mantra “git init” which creates these 3 sections in GitLand. These 3 things are …

1. Storehouse (Repository)
2. Magical Truck (Staging Area)
3. Workshop (Working Directory)

$ git init

As we can see, all of these 3 sections are empty now. This is because we have just created 3 sections and haven't started working on our car project. Ram the carmen start working on his new project in his workshop, after a long day, he finishes with the frame of the car.

Ram is happy about his work and wants to save this version of the car in his storeroom, so that, if tomorrow, while working on the car if something goes wrong, he at least has “this version” safe and sound and can easily get back this version from his magical Storeroom. However he cannot directly store this version of the car in the storeroom, he needs help from the magical truck. We need to move our changes to the magical truck to store this version of the car in our storeroom. You might think the act of moving will remove the object from the source i.e Workshop and put it into the destination i.e magical truck. However, in GitLand when we add any object to the magical truck, it creates a copy of the object and the copy gets into the magical truck. That's the reason why the truck is called magical. This gives many benefits as we can compare between a) Workshop and Magical truck b) Magical Truck and Storeroom. Ram adds the frame to the magical truck using another Git mantra “git add <name>”

$ git add car_frame

As you can see car_frame is present both in the workshop and truck. This happens because the magical truck copies the added object into it, as explained before. Before he stores this version available in the truck, permanently into his storeroom, he realizes that he just missed adding doors to the frame which makes car_frame incomplete. He quickly creates the door in the workshop and attaches it to the car.

He can compare what changes he has made to the car project since he added something to the truck by using the “git add” mantra. He uses another special mantra “git diff”.

$ git diff  # Output: New door is added to the car

By default “git diff” shows the difference between objects stored in the workshop and the magical truck. Once he is satisfied with the doors, adds the doors to the magical truck with the “git add” mantra.

$ git add door

He reviews everything in the truck and stores this version of the car project. He uses another mantra “git commit”. Once again the truck shows its magic and creates a copy of objects present in the truck and stores the copy in the storeroom.

$ git commit

git commit

After storing the copy of the version available in the magical truck, “GitLand” marks this version(blue border). This is done to know which version is currently being worked upon in the workshop. Right now we have only one version, but as we save more versions, the concept of highlighting will be more clear.

In this way, all the 3 sections store the same content. Once a version of the car project goes into the storeroom, Ram can be assured that he can modify or experiment with the version of the car available in his workshop. All changes will only take place in the workshop, if something goes wrong, he can always bring the version of the car stored in his storeroom and start working from that point. It's like creating a savepoint so that you don't need to work from scratch in an unfortunate event. Or, if new modifications are well and good, a new version of the car can be stored in the storeroom. This is the reason why Git separates all the work happening into these sections.

Tip: New work can only happen in the workshop, you cannot directly change (add/remove features) car copy in the storeroom or magical truck, it always happens in the workshop.

Day 2:

Ram adds wheels to the car in his workshop.

Make wheels in the workshop

Quiz:
Question 1: What happens if Ram commits now? (answer, bottom of the page)

Before Ram adds wheels to the truck he compares work in the Workshop and magical truck using the mantra “git diff”

$ git diff  # Output: Wheels are added in workshop

He realizes that he has added wheels but missed adding a spare tire.

He adds a spare tire to the car, in the workshop (changes can happen only in the workshop)

Add tire to the car in the workshop

Afterward updates the magical truck with new changes using “git add”

$ git add wheels, spare_tire

git add wheels, spare_tire

Now he is happy with the version on his magical truck and wants to save this version of the car project in his storeroom. Again uses the mantra “git commit”. In our storeroom, we will mark this new version as the “active” version as it's currently active in the magical truck and storeroom.

$ git commit

git commit

Wow, we have both versions permanently stored in our storehouse.

Day 3:

In the same way, Ram paints the version of the car, available in his workshop with yellow color, and stores this version too, in the storeroom so at the end of day 3, these 3 sections look like below and mark V3 as active.

Paint car in yellow, move to the truck, store new version(v3) in the storeroom

Ram is very happy that he completed his project in 3 days and shows the completed car(version 3) to the client. After seeing this beautiful work, the client is also satisfied but has one problem, though he mentioned in his specifications that he wanted a yellow-painted car, he changed his mind to a red-painted car. He asked Ram if this change will cost too much, as he might need to redo the entire project. Ram said not to worry to the client, as he has stored every version of the car in his storeroom, while he was working on this project. More specifically version 2 Is a version of the car which isn’t painted.

Reward Day 4:

Ram brings version 2 from the storehouse with the help of the magical truck. He uses a git mantra “git checkout <version>”

$ git checkout v2

This mantra copies version 2 and loads the magical truck with the copy of version 2 of the car. As told before, the storeroom always marks the version which is active in the workshop and the magical truck. In this case, it is version 2, so it marks version 2 as active.

git checkout v2

Ram paints the unpainted version 2 of the car with red paint and stores it into the storehouse using the same procedure of working in the workshop, then loading changes in the truck, and finally storing it into the storehouse using the Git mantra “git commit”.

Paint car in red, move to the truck, store new version(v4) in the storeroom

As you can both version 3 and version 4 uses version 2 as their base version, this will help in merging changes which is a little advanced topic and we will talk about that in some other chapters.

Now the client is happy with version 4 of the car. As you can see, initially the using GitLand and its 3 sections seemed a little extra work, but they, give satisfying results in an unfortunate event when something goes wrong or we end up doing certain things which are out of scope, along with many other benefits. For example, 2 mechanics can work on 2 different features of the car, using the same base version, one can work on wheels, while the other is working on the engine. Later both these versions can be merged as a single unit.

Connections between GitLand and Git

As you would have probably guessed there is definitely a connection between GitLand and Git.

1. Storehouse → Repository
   Ram stored the different versions of his car in the Storehouse. Similarly, we use Git’s Repository to store all the versions of software as we make them.
2. Magical Truck →Staging Area
   In GitLand a magical truck was used to move changes from Workshop and Storehouse. This gave us the luxury of differentiating between work in progress and the next version which is going to be stored in the Storehouse. Similarly, there is a concept of the Staging Area in Git which is precisely used for the same purpose.
3. Workshop → Working Directory
   In GitLand, all work happens in Workshop. The work may be adding new features or fixing some fault in the Car. Similarly, the working directory is the place where work happens.

In the next chapter, we will do the entire process in code and show you guys how you can create all the versions of cars on your computer, with actual Git semantics and commands. It is going to be exciting.

Quiz Answers

Question 1: What happens if Ram commits now?
Answer: Since nothing new had been added to the magical truck, more precisely, there is no difference between the version available in the magical truck and the active version in the storeroom. “GitLand” refuses to store(commit), as there is no new version.