Let’s GIT It!!!

A guide to get started and visualize GIT and its operations.

“code editor using git for version control” by Yancy Min on Unsplash

To all the software developers out there, how many times did you find yourselves struggling with git and its so many commands, most of us would just follow the steps given in a YouTube tutorial or its documentation having no clue what exactly are we doing!

Many would rant about saying:

Yeah, we have heard push or a pull or commit but whatever!! We don’t know what any of that means and yes we did try all other approaches like asking a friend and realizing NOT EVERYONE IS A GOOD TEACHER and also thought to join some course and alas realizing there are too many!!

And yes of course if you guys are like me, we have our own tantrum of wanting to learn in a visual and fun way.

During this process, I learned a very beautiful lesson, which has now become my prime learning theory, which I am going to share with you along with fun analogies to understand git operations and not be so clueless as to what you are doing with git.

HOW TO APPROACH LEARNING

Many might have heard about the 20–80% rule, I like to even call it the onion rule. It basically states that to do a particular task, just 20% of the knowledge is repetitive and rest we rarely use. This means that if you first start with the basic key concepts that comprise 20% of the topic and then later continue reading elsewhere you will find the same key concepts being repeated every other place with some extra bits of information.

Our learning and storing information system is no longer like a stack of new info all the time but instead like an onion peel, as shown in fig 1.

• The first little chunk of key concepts
• Then a peel of little extra concept surrounding it
• .. and then another peel of extra concept surrounding it.

Fig 1 - Photo by me (created in PowerPoint Presentation)

SO WHY AM I TELLING YOU ALL THIS?

Cause this article covers the basic key concepts in an easy to visualize way with the help of analogies. You can consider it to be a guide to basic repeating key concepts.

Yes, most important take a paper and draw a mind map to whatever is written, it’s a very helpful way to actively read and learn.

LET’S GIT INTO IT

Everyone says that a programmer should know git but WHY? Ok, we get that it provides us with a platform to collaborate with other developers … but how?

To answer all that let’s start by digging deeper and more fundamental by questioning the very basics: WHAT IS GIT?

On Wikipedia we get this result:

“snapshot of search-git on Wikipedia” from the Wikipedia page

And yes of course wiki is right but that doesn’t make sense for a person who just got into learning git.

So, let’s break it, it’s a distributed system that means the code is not centralized meaning it’s not restricted to being in just one system, we can have access to the same code on several systems, as shown in fig 2.

Fig 2 - Photo by me (created in PowerPoint Presentation)

A version control system, is basically that it’s able to save the snapshot of the code (we call the snapshot of the code as a version) in the history and we can have access to the previously saved versions anytime. Commit is the process of saving the version, so saving version is the same as committing changes.

HOW DOES THIS WORKFLOW OF VERSION CONTROL WORK?

So first let’s get our vocabulary updated

You have a folder and if you have a .git folder in it, it’s now called a repository, as depicted in fig 3.

Folder + contains .git folder = Repository

Fig 3 - Photo by me (created in PowerPoint Presentation)

Yep, it’s a fancy name. Having a .git folder basically means that git now has control over the folder and we can use git operations on the contents of this folder.

Ok, I smell another question coming WHAT ARE GIT OPERATIONS!!! They are push, pull, add, commit, clone, and all other operations you might have seen if you have searched about git before or even heard about it. About these individual operations, we will get to know later in this … documentation?

How does one create a .git folder inside a folder?

Well, in your git terminal go to the folder in which you want to create a .git folder and enter: git init

There are two types of repositories that you will be working on.

1. One is the local repository that is the repository in your local machine which is the pc or laptop that you are working on.
2. The other is the remote repository which is the repository in the cloud basically the internet. Everyone has access to that repository.

SUMMARY: 
Folder + contains .git folder = Repository 
git init //to create a .git folder 
We have two types of repositories: local and remote repositories

IN THE LOCAL REPOSITORY

Here we will be talking about the local repository and later we will go to the remote repository. In the local repository, we are having three stages: working directory, staging area, and git repository. Let’s try to understand what these three stages are …

IT’S STORYTIME!!!

Imagine that you are a photographer and you got a project. For that, you will be doing an initial setting regarding background, brightness, color combination, dress, positioning & posture of the model, etc. You of course wouldn’t take the final shot until and unless you check how is it going to look through the lenses.

1. Here setting up your studio and making little changes is what you call as the working directory
2. To check the final look of the whole set up you look through lenses. Checking the overall look of all the little changes that you have made (i.e. changing lighting, color contrast, positioning of model, etc.) can be done through the lenses is parallel to your staging area. So whatever you see through the lenses is your staging area.
3. After this, when you got the perfect shot, the final click of the scene is parallel to whatever you save in your git repository in the form of a commit. So your commit is the final picture you clicked.

Fig 4 — Photo by me (created in PowerPoint Presentation)

Now that you got a clear idea about the three stages in our local repository. Lets us next learn how to traverse between these stages:

TRAVERSING BETWEEN STAGES

Working directory: After editing the file if you save it, the changes will be saved in the working directory.

If you want to check in what stage your work has been saved then you run the code: git status

Clip by me of Git Bash terminal

This means that the changes are saved only in the working directory.

Now, what if we want to undo changes from the working directory, and go back to the previous save:
git restore <file_name>
git restore README.md

Staging area: adding is the process of sending the changes from the working directory to the staging area. To add using git command prompt you write:

git add <file_name>
git add .  //to add changes all at once from the many files

Many have this doubt that why have this extra stage why not just commit it. This is because:

1. It creates one more layer of protection
2. It’s useful to preview the final product somewhere before finalizing it and saving in history, rather than committing several times that it will be difficult to keep track of.

Now, if we run git status we get the following response:

Clip by me of Git Bash terminal

This means now changes are saved in the staging area.

To remove changes from the staging area and go back to the previous save:
git restore — staged <file_name>
git restore — staged README.md

Git repository: Yeeaaahhhh!!! We are finally there!! (Let’s click our picture!) To commit (or to save changes) in the git repository we use the git operation called commit: git commit -m “message of commit”

Clip by me of Git Bash terminal

On running git status we get the following response:

Clip by me of Git Bash terminal

This means now all the changes are saved in the git repository like a snapshot of the code, and the commit history is recorded and saved.

LET’S SEE THE TIMELINE OF OUR COMMITS

To see the history of our commits that is a part of this repository: git log

Clip by me from Git Bash terminal

But all that is just too long and not easy to read. So you just want to see the commits and their id, and beautify the way it looks in end, to achieve this you could use the following code: git log — oneline — graph — decorate — color

Clip by me from Git Bash terminal

There are three ways to undo commit:

1. git checkout <id_from_log>
It moves to the specified commits (commit is mentioned through the id of commit)
2. git revert <id_from_log> … write the commit message for your revert changes … shift + : wq
   Hmmm, to understand this you are a photographer again!!
   You took a picture for your client (click=commit) pic1, he didn’t like it. He asked for modification! And again the same process of modifying and clicking another picture (click) pic2 … again (click) pic3 … and again (your client is a confused dude) (click) pic4 … and finally (click) pic5
   Wooah! That was a hard task.
   Now you want to delete pic3 and pic4 changes but also don’t want to delete it permanently (what if the confused dude comes back again having second thoughts on pic3 and pic4!!) revert is to our rescue!
   What it does is, it creates another commit that deletes the commits we don’t want. This means that you created another picture that deletes the existence of pic3 and pic4. This way now we can still check out to our previous commits.
3. git reset <id_from_log>
   This removes the saved changes permanently from the staging area and the git repository, but the removed changes are still saved in the working directory
4. git reset <id_from_log> — -hard
   Now on adding hard we have removed the changes from all three stages of the local repository

Yippieeeeee we finally made through the LOCAL REPOSITORY!!! And all the basic git operations that could be used there.

Summary
Working directory — — (git add .) — — à Staging area — — (git commit -m “blah”) — — à Git repository
git status // in what stages is your work saved
git restore <file_name> //undo changes in working directory
git restore — staged <file_name> //undo changes in staging area
//undo commit
git checkout <id_from_log> //moves to previous commits
git revert <id_from_log> //deletes previous commits temporarily
git reset <id_from_log> //deletes previous commits permanently (if merged)
git reset <id_from_log> — hard //deletes previous commits permanently (if not merged)

BRANCHES AND REMOTE REPOSITORY

Well, you can imagine branches to be the timelines, and the commits to be the events that happened in that timeline.

The remote repository is nothing but the repository you have on your GitHub.

What’s the use of this remote repository?

Without it, you can’t make other people see the code because this provides you a way to make your code visible to everyone through the internet. So, GitHub could be said like a common repository dumping ground for all the developers to see each other’s codes.

IT’S STORYTIME AGAIN!

So far, we have been showing the final picture to our client through our local machine (means face to face). We have not yet made our pictures accessible through the internet.

You would want to make it public if you want to collaborate your work with other photographers, which is possible by using the remote repository. Let’s change our analogies a bit, and get to a more practical environment of actual coding from photography.

Let us assume you made your remote repository, which by default will have just one branch which is called the master branch. We can create new branches but again what’s the use?

Some might answer, we require it for collaborating in teams.

BUT Y?

Let’s get to our story, you are now working in a team and have to build a little application let’s say a simple website. You are three members in a team, and you want to split your task so let’s say student1 gets to make the navigation bar student2 gets to make the inside content and pictures of the about me page and the other student arranges the content and pictures for the contact me page.

Now without git how would you guys collaborate? How would you merge your code in the end? Would you send each other your code through mail or drive?? Would you manually go line by line and then find the contradicting code then merge? Isn’t it kind of time-consuming. TOTALLY!! It is!!!

Creating new branches in git is to our rescue!! Ok, we understood the problem area and know what the solution is but now how to apply the solution?

Well it’s simple, all three of them create their own new branches in their local machine, make required changes in them individually then they could push it to the remote repository then merge it.

REMEMBER: It’s important to first push then merge

How it should not be:

If we first merge the branch locally with the master branch then push the changes to the remote repository, this makes changes to the master branch of the remote repository which is accessed by other developers and they might not like the changes made by you.

How it should be:

Everyone should individually push their branch to the remote repository and then all the developers in the team could discuss which feature to keep and what not to keep and accordingly merge the branch with the master branch in the remote repository.

On merging their code, git does the hard work for us to find the places where changes are made and are contradicting our previous code and then we can manually go there and change it accordingly. On merging with the master branch git produces a commit called the merge commit.

By now we also understood the third point for our wiki definition of git that it’s designed to coordinate among programmers and track changes.

CREATE YOUR REMOTE REPOSITORY

We are done with understanding what happens behind the scenes, next we shall understand how to do it practically on GitHub.

Click on this button to create a new repository

Clip by me from GitHub

Fill in the detail as shown then click create repository.

Clip by me from GitHub

Copy the SSH URL if you have set your SSH authentication (given how to do in the end), else use the https link.

In Git command prompt in our master branch:
git push -u <paste_url_here> master
-u is added the first time we are pushing to the remote repository, to establish an upstream link to our remote repository and our local repository with our master branch.
master: is to specify which branch you want to push to
< paste_url_here >: now to push we don’t want to use this URL again and again so instead we use origin in its place after writing this code:
git remote add origin <paste_url_here>

NOTE: if you are having a problem with another link existing already in origin or origin not existing see my code solution below in the end

PUSH YOUR CODE FROM LOCAL TO REMOTE REPOSITORY

git pull origin master
It fetches all of the code from the remote repository and then merges it to the master branch of the local repository. This is a good habit to develop so that we are on track with the changes that took place in the remote repository by other developers

git branch feature1branch
git checkout feature1branch
or
git checkout -b feature1branch
This is to create a new branch called ‘feature1branch’ and switch to that branch from the master branch

git branch -d feature1branch
to delete ‘feature1branch’ if the branch is merged

git branch -D feature1branch
to delete ‘feature1branch’ if the branch is not merged

to merge, you should be in the master branch
git merge feature1branch

if error occurred
make required changes
add
commit
shift + : wq

CHANGING THE ORIGIN

git remote -v //to get the value of origin
git remote rm origin //to delete the current origin
git config master.remote origin
git config master.merge refs/heads/master

SETTING SSH AUTHENTICATION

cd ~
mkdir .ssh
cd .ssh
ssh-keygen -t rsa -C “tanisha1@gmail.com”
Enter file name where you want to save your ssh key (./id_rsa): 
Enter your passphrase:
Re-enter your passphrase:
notepad id_rsa.pub
Copy the content inside notepad and paste in github/settings/SSH keys/name of device: Laptop … Paste the content here
Do you want to establish connection: Yes

CONGRATULATIONS

Finally, it’s OVER!!! And you have made through such a loooonnnnnggg article!!

By now you will be having a beautiful picture and story on:

1. What is git and …
2. How some of its basic operations work

… and I assure you that grasping other concepts in this topic will be easier for you.

WHAT TO DO NEXT?

You can go ahead with finding tutorials on Udemy or YouTube, to get the visual and practical experience of working with git, and by then you will be more capable of reading and understanding the official git documentation whenever stuck. You are good to go!!

ABOUT THE AUTHOR

I like to explore difficult looking concepts in a fun and engaging way and share my exploration with others.

Hmmm, and as of my technical knowledge, I could be called as a frontend web developer.

Feel free to connect with me on my LinkedIn account for more topics you would like me to write about https://www.linkedin.com/in/tanisha-bisht-17542a192/