Table of contents
No headings in the article.
In the previous module, we understood about Version Control System. In brief, a version control system is software that keeps track of changes you make in a file. We also learnt that Git is part of Distributed Version Control System (DVCS). In this tutorial, we will deep dive into What is Git and how it works. So, without any delay let's start it.
If you go back to the history of Git, it began with controversy
You may know that Git was developed by Linus Torvalds, who was also the creator of the famous Linux Kernel. In the beginning, Linux Kernal was using a DVCS called BitKeeper, but due to some issues, their relationship broke down and from there, with some of the knowledge of BitKeeper, Git was born.
Everything will start with two magical words, "git init", and there is no going back.
Now, why I said that?
So, to turn your folder or directory into a local git repository, simply enter the command git init in your command line. This will generate a .git folder within the chosen directory, effectively turning it into a git repository. The .git folder is everything. This will be responsible for storing all of your data and tracking down all changes that will happen in the folders.
Now you are under Git's Surveillance
From now on every time you make changes to the working folder git will note every change. In the beginning when you just created the .git folder, if you make some changes in any file and check the status with the git status command, it will show you the list of the names of untracked files and will suggest you use git add <file> to make them tracked. After you add them, whenever you make some changes, Git will mark that as modified and show you a list of modified filenames. This is called Modified State in Git's language. You can check this by using the git status command, it will mark the changed file/files in red and it will automatically suggest you use the git add <file> orgit add .(to add all the files in one go) command to officially mark or register the changes. This is known as the Staged State. And to safely store the marked data in git's local database you have to use the command git commit with a -m flag and a message to label the commit while storing the data. It looks like this: git commit -m "your message".
We will learn more about Git's command and their functions in the upcoming tutorials.
So, if we summarized everything, the main workflow is:
You make any changes in the folder or working tree(everything in the folder except the .git folder)
You are staging those changes.
You are committing those staged changes to permanently store them in the git repository.
Up to this part, we discussed everything basic and general. In the next part, I am going to discuss the inner structure of the git folder. Now if you don't want to learn in that dept you can happily skip the next part and wait for my next tutorial. I am not going to curse you.
But I am a bit like a mole. I love digging. Whenever I choose to learn something, I try my best to cover everything, everything may sound a bit hypothetical but try to understand what I want to say. So if you are like me( I am not trying to discriminate, don't take it offensively), Welcome, to paradise my friends.
What is inside the .git folder?
.git folder contains all information required for version control. If you want to back up or clone your repository, copying this single folder elsewhere will give you nearly everything you need. Inside this folder, you will find a bunch of folders and files. Now, the number of files and folders may vary depending on what kind of work you are doing(like connecting with a remote repository or not, number of branches etc). So to know the exact number I read gitrepository-layout and Git-Internals-Plumbing-and-Porcelain both with another bunch of blogs. In gitrepository-layout, you will find way too much information that may not be present in your .git folder. In Git-Internals-Plumbing-and-Porcelain you will find a little lesser(for example log folder). So after reading the official git book, numerous blogs, stackoverflow answers and running multiple experiments in my system, I conclude the followings:
hooks/: This folder contains your client or server-side hook scripts. When we do git init some sample hooks are installed. But these are disabled by default. If you remove the .sample suffix from the filename you can enable this file.
info/: Inside this folder, there is a file, named exclude which stores excluded patterns that you don’t want to track in a .gitignore file.
logs/: It stores the records of all the changes you made. If you open the files you will find information about the log details, like what kind of changes you made, your name, email etc. Here you will find a HEAD file and a ref folder.
logs/HEAD: This stores the information about all the changes that have been made.
logs/refs/heads/branch-name: This stores the information about changes made in that branch.
logs/refs/remotes/branch-name: You will find this folder if your project is connected to a remote repository. This folder saves the information about changes in that particular branch of the remote repository.
objects/: This folder stores all the content for your database like files, commits etc. Initially, you will just find a pack and info subfolders.
objects/[0-9a-f][0-9a-f]: Every time you staged something 1 folder will be created for storing the backup of the change you made. After you commit it will create another 2 folders for storing the directory listing or tree for the commit and another for storing the commit message. The output of your commit and git add is a 40-character checksum hash where the first two characters of the hash (SHA-1 hash) are the name of the folder and the rest 38 characters will be the name of the file inside it. Objects found here are often called unpacked (or loose) objects. You can read this blog for more in-depth knowledge.
objects/packs: you will find pack files here. Pack files store many objects in compressed form, along with index files to allow them to be randomly accessed.
objects/info: Additional information about the object store is recorded in this directory.
refs/: References or commit hash(40-character checksum data generated by SHA algorithm) into the commit objects are stored in these folders.
refs/heads/branch-name: This records the most recent or last commit SHA id of the objects of that branch-name.
refs/remotes/branch-name: If you have connected your local repository with a remote repository or cloned a remote repository only then this subfolder will be created. It records the most recent or last commit objects of branches copied from a remote repository.
refs/tags/name: This records any object name (not necessarily a commit object, or a tag object that points at a commit object).
COMMIT_EDITMSG: This file stores the message from your most recent commit or last commit.
config: This file contains your project-specific configuration option.
description: Used only by the GitWeb( Git web interface) program.
HEAD: Points to the branch you currently have checked out or the current branch.
index: Here Git stores your staging area information.
packed-refs: Records the same information as refs/heads/, refs/tags/ but in a more efficient way.
So, here we come to the end. I wanted to write more, but I realized that will be way too much information for "What is Git?". Beginners may find this tutorial a lot extra for the "What is inside the .git folder ?" part and may not understand everything, I completely get that but I intentionally put that part in this tutorial to show you how awesome Git is and to create the spark in you and make you feel the joy that I felt when I learnt Git. So yeah, I hope you are enjoying my tutorials, and we will eventually go through each and every topic. After the end of the entire series, if you come back to the "What is inside the .git folder ?" part, everything will make sense then. And an end request from my side, try everything on your own, don't just buy anything that I am saying in this tutorial. When you try things on your own, you will feel the confidence and the joy of knowing something extra.
So enough for this tutorial, meet you guys at my next tutorial. Bye!!!
Previous: Introduction to Version Control System