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
i.sub-topic-summary.note
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.
So,
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
to…
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
to…
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.
, so, I thought to share it as it might help others, seems I was wrong!
).