I know blogs can be real dull, and when it involves git, it is even more boring. Ahh, I feel like taking a nap already 🤣 . Forgive my pitiful effort to make a funny blog. I'm trying, folks. But let's get a bit serious now. Git is one of the most underrated skills in tech because it becomes obvious: if you are a dev, you should know git. Git can make or break a dev's career (if you would like to know why it's so important, check out my previous post here ). So it is crucial to understand a few basic git terminologies before diving into the commands. This blog post is dedicated to helping you understand that.
The Repository
The most important term you will come across in the git world, the heart of git: the repository
Git keeps a record of all your files and the history of all the changes made in every single one of them. And all this information is stored in a special file called ".git". Any folder, which contains this special .git file, is called a 'repository'. That's all. Simple, right? 😉
Clone
You would come across this phrase frequently: Clone that repo. And below is the git command associated with it.
git clone <repository_link>
Let's try to understand what this command does. In English, clone means to duplicate or create a copy of something. That is exactly what the command given above does. This command is used to make a copy of any repo (short for repository) on your local device so that you can start working on that project. Note that to clone a repository, you will need access to the repository. (We'll talk more about these settings in a later post 😅)
Local
I know it's almost lame of me to mention this, but I'm trying to cover all frequently used terminology. Local just means the device in which you have "cloned" the chosen repo. The device where you have the project folder and are making changes.
Remote
This term is often used to make a reference to the code/files present in the cloud (GitLab, GitHub, etc.).
Origin
Origin is the term used to refer to the repo URL which contains your code in the cloud (GitLab, GitHub, etc.). Instead of using the actual repo URL in git commands, we reference those URLs are 'origin'. Remote and origin are often used interchangeably (which is inaccurate). In the upcoming posts, once we start playing around with git commands, you'll be able to appreciate the difference between these terms.
Main
Every git repository, once created, keeps track of one finalized version of your project (like how every tree has only one bark). This finalized version is given a name called "main" and the code present in this location is the one to be hosted or released (according to the convention). Whenever you want to make some finalized changes to your project, those changes are made in this location called the "main".
Branch
We now know that changes that "go live" are stored in "main". But what about experimental changes? How would you track those changes, and where will those be stored? This is where "branch" comes in. Whenever you want to make changes but are not sure if they should be published, you will make a copy of the main branch and give it a name. This copy is called a branch (just like how tree branches spring from the bark). Fun fact: main is also a branch. When the changes made on a branch are finalized, these changes are "merged" into the main branch and hosted. We'll learn more about "merge" in the upcoming posts. For now, you can think of it like a tree branch getting re-attached to the bark.
To truly understand git, it is important to visualize it. Think of the main branch as the main bark of a tree. And then, every time you create a new branch from the main branch, visualize a new tree branch growing from the bark. And think of the file changes you make on each git branch as the dollar note in the above gif. This structure where git maintains a list of files and history of changes in a structure similar to that of a tree is called the git tree. You might not appreciate visualizing a git tree now. Still, as you start making long and complex changes across various branches simultaneously, visualizing the git tree is beneficial.
That's all for this post folks. We'll get our hands dirty in the next post with a git setup walkthrough.
