Learn Git - An Analogical Approach (Lecturer and The Student)

I wrote this guide on my blog late last year, it is a simple guide to understanding the basics of git using almost an analogy approach. I believe if you can understand the basics of git, then you can get a clearer picture of how it works on CLI, Github, Gitlab and the likes.

Note: This is my take on how I understood it, please, do not hesitate to correct me if I am wrong in some cases!

let’s get started…

Understanding of Git in Layman’s Term

Git isn’t the same as Github. I’ll clear that in a min

Git is a free and open-source distributed Version Control System (VCS) designed to help programmers to handle everything from small to large projects with utmost speed and efficiency.

A version control system allows you to track the history of a collection of a file, as well as the functionality to revert the collection of files to another version.

Obviously, the collection of files is usually the source code for a programming language, but the concept of version control system applies to other typical version control systems, where you can put different types of a file under version control.

What does that mean?

I’ll use a Notebook/Folder structure as an example to illustrate my point:

If you recall, I said, Git is a distributed Version Control System, let’s say you have been giving an assignment by your lecturer or teacher (whatever you call them) to write about the “Importance of Life”.

Your lecturer gave each student a new notebook to write about the topic and gave you some outline to follow, like a sub-topic, what did he do?

You will say he Distributed the notebook right, so everyone would have a copy to write about the topic.

Now, let’s make some magical assumptions:

For every new sub-topic you create in that book, you will always have a new book embedded in the book, like, a book inside a book. One sub-topic means you have another book inside the book, and two sub-topic means you have two books as a sub inside the notebook. Another way to think of this is by using a Folder, for every new sub-topic you have a different folder for that, e.t.c

The below image explains it better:

Look at that structure:

Every folder has its own note, including the master folder or the master notebook. importance of life.note is the name of the master note, it contains basic instruction about the topic in general, then you have sub-topics, with its respective note.

This is where it is gonna get interesting, let’s imagine you have some basic note in the i.sub-topic.note, which is located in the 1.Sub-Topic folder. Okay, you have a note, and you know sometimes, you might have some basic jottings you want to quickly write down without affecting the main note, in this case, i.sub-topic.note.

So, you decided to store the jottings inside the same sub-topic folder, and you titled that i.sub-topic-jots.note.

This file will be meant for the jottings of the particular sub-topic/sub-folder.

This is the structure we have so far:

The reason you have that jotting note is to jot, and then push/move the content into the main note of the sub-topic.

Sometimes, the jottings are used for corrections in the main sub-topic.note file, while sometimes they are just simple jottings, as you continue updating, deleting, and creating new content in the note, you will always lose track of what has been modified in the note or when and why you added the new updated/modified content in the note.

Hint: To solve the problem of losing track of what has been modified, added, or deleted, we need to emulate the idea of a version control system. If you recall, a version control system helps tracks the history of collections of files.

To keep track of what, how and why you modified the content inside the i.sub-topic.note file, you decided to create a summary of your changes, and you titled that


Note: Anytime, you pushed your changes to the main file, the jotting files are deleted, that is the reason we need this summary, it tells us what is deleted, what is modified and what is added.

This is our current structure:

Don’t be surprised you can’t find the jotting, I told you when the changes are pushed to the main file, we delete it, and then we summarise what and why we deleted it in the
i.sub-topic-summary.note file.

Now, repeat that for the remaining sub-topic folder, you have a file, whenever you wanna make changes, you make it in your jottings, when the changes are pushed, you saved the info of what has been pushed in your summary note file, and then, you delete the jotting file, leaving the summary note intact.

What you have visually is a book that has different sub-books, which has different notes, and summaries, respectively. Git is more than this, but this would quickly give you an edge and an understanding of Git.

You can fairly say this is a really tedious process if done manually. Now imagine a tool that could take care of the steps for you; it handles the heavy-lifting for you.

Now, you can boldly say, a Git is a distributed Version Control System, and because of that, anyone who works in that particular project will get a complete copy of the project or an outline of the project can be created and distributed, just like the Lecturer distributed the copy of the notebook.

Every change you make lives on a branch, anytime a repository is created (the repository is the place you store your files, don’t overthink, the repo is the notebook), a default branch is created which is called master branch, and that branch is the record of all the changes that have happened to the repo, that’s the next thing we will be demystifying.

I won’t leave you hanging with another definition of a branch. Instead, I will expand on the concept we have adopted so far to explain the meaning of a branch, and its uses.


What is…

Git Branch In Layman’s Term

In our first scenario, we discussed the Git concept itself; let’s dive deeper into the concept of the Git branch using a similar approach.

In the first case, the Lecturer distributed a notebook and gave you an outline on what the topic should entail, in this instance, assume the lecturer is giving 5 students a copy of his notebook, this time around, you don’t need to write everything from scratch, the notebook is filled with necessary details and it also contains sub-topics.

The lecturer wants you and the other students to collaborate, and improve on the topic. It doesn’t make any sense to use a single notebook, that was the main reason he shared a copy to each student.

You all have a role, you might be fixing a typo, while others might be enhancing the vocabulary of the project.

In a simple sentence, what you have all done is branching out from the lecturer’s original copy, and you all have an independent copy, this is useful because it becomes easier to merge to the original copy, no more fighting over the lecturer’s copy.

With Git, a branch is created automatically the first time you initialize a project. The branch is called the Master Branch, that branch contains the record of what has happened in that project, the lecturer’s copy is the master branch.

It doesn’t make sense to create all your code in the master branch, so, when you have any important bug to fix, or you want to add new features, then you create a new branch, for example, ‘Features X’ branch, `Fix X’ branch, you get the idea!

This is good because you won’t affect the master branch.

In the student scenario, it allows you to isolate your work from others, after the completion of your fixes or new features, you can merge it to the Master Branch, after merging, you can delete it, as it isn’t useful any longer, you won’t be able to do that as there still some concept to cover, trust me, if you understood the above concept, then let me introduce you


Committing Your Changes

A branch is like a pointer to mark a specific point in time, it allows you and others to easily identify what changes to expect and also makes retracing easier, in case, things go wrong.

After you have created your branch, you made your edit; the next thing is committing, committing is a way of adding changes to your project or to the project.

Perceive it this way: When you commit, it means you take a snapshot to your project at that point in time, it can be a single change or lots of change bundled together, if that’s confusing, just remember, that committing is a way to add a change to your project, and if the changes are added, it records all the changes at that point in time.

Before I go further, let me introduce you to Github.

Github is a collaboration platform leveraging the power of Git. It focuses heavily on the people who create the software, the main advantage of Github, is the ability to integrate collaboration smoothly into your Git repository, you can discuss changes with other developers, contributors, and other team members.

Good, since you understood the difference between Git and Github, I guess you also have an understanding about a branch, committing, so, this is the perfect time to introduce you


Creating Pull Request (PR)

Once you’ve made your commit, the next step is to create a pull request, the commit you made isn’t added to the master branch, the commit is still living in your project copy, you need to create a pull request to submit your changes to the production branch.

A pull request is a Github operation, and when you make a pull request, you are telling your fellow contributors, you want to show the changes you’ve made locally or the changes in your branch, and you want them added into the production branch on Github.

Once you’ve created the pull request, everyone will be able to view and discuss the changes you’ve made by commenting and leaving feedback on your changes.

The purpose of using the pull request is the collaboration aspect. It is important you receive thoughts from other contributors in other to make the project better.

Best Practice: The best practice is to create the pull request in the process of committing, so you can get feedback earlier, don’t try to work on everything before submitting your pull request, after all, it’s collaboration, so, it makes a whole lot of sense to discuss earlier before diving deep.

If your pull request is accepted, the next thing is to deploy from your branch to the production branch.

If you’ve made it this far, then congratulation, hopefully, you get the basic concept of git.

The next step is downloading and setting up Git using the command line, creating your local copy of a repository, creating a new branch as we discussed earlier, committing and so many more.

Don’t worry, the majority of this would be done using Github Learning Lab. It is an interactive environment that works you on how to get up and running in Git and Github.

@ozfiddler wrote a detailed guide on using git with Github Desktop, you can learn the nitty-gritty there if you prefer to go with the GUI route instead of CLI.

I’ll appreciate it if you can contribute to this guide, like the stuff I am missing or other tips, thanks.


Wow, you made that really complicated to follow. If that is Git, then no wonder I don’t like it!

Sorry it didn’t help, that was just the way I was able to learn it ;:slight_smile: , so, I thought to share it as it might help others, seems I was wrong!

There’s no need to apologize. …and don’t let one negative comment derail what you’re doing. I’m sure this will help a lot of people. Good on you for doing positive things in the community.


Wow, that was supposed to be layman’s terms?

I feel really stupid now. But I am an old git.

When you are developing something (can be a software, a plugin or as in this example a book) the simple way is having your files on your own PC, change them any time you want until you get what you wanted.
It you are developing something in collaboration you can have all the files on a share and anyone can edit, add, change anything.
It’s fine (here someone will kill me :sweat_smile:).
But, and it’s more true when your project grows, you’ll face this and many other situations:

  • You add a great feature that breaks another feature and you want to revert
  • A want to take back to a removed feature
  • You and your collaborators are changing the same file
  • You want to try 2 different endings for your romance
  • You want to keep track of who and when changed a file in what way
  • You introduce a wonderful feature but you first want to test before make it public
  • You want all of your users/readers to suggest changes or fix things

A Version Control System is a software/protocol that take care of this. Is a sort of logging system/time machine/collaborative environment designed to handle with the above problems.
Git is one of those.


This is pretty much the way I think of it also.

Extending the concept to the notebook analogy in the original post:

I have a notebook with all of my code in it. I can make a change and commit (save) that change, but when I commit, what I’m really doing is making a new, instant copy of the entire notebook that also has a reference to all of the previous saved (committed) versions. This version history can also differ across branches (I can maintain multiple histories at once for different changes) and across the versions of the notebook that each person working on the project has created.

git gives us the tools to manage all of this and do all of the related operations, like visualizing differences between versions of the project and merging them together. There are some terms and concepts that are important to get to know in order to do this well, but once you do that, it gives you a much better way to manage your code than passing a bunch of files back and forth.

GitHub is a layer on top of git that gives us a more friendly web UI and easier ways to push and pull changes (copy our work between our computers and the internet so that other people can view and manipulate them).