Inside Git and .git Folder

Git acts as your second brain for source code, so you don’t have to remember everything, from major changes to minute details. It remembers everything just like court case files. It documents everything into the .git folder, which is kept within the project.

Before understanding the .git folder, let’s take a look at how the .git folder comes into the picture. When you start a project, it is a file or a directory, and once inside that directory, you run git init It turns that normal directory into a git repository on the local. And that’s how the .git folder is introduced.

If the .git folder is explored now, most of the folders and files would be empty with little to no information at all, but these are essentials that are needed to work, and it means git has set up its base in the directory. Working directory is untracked. U can be observed alongside the files.

Before moving forward, once you have made changes in the source code here on now. All those files and folders will be untracked until staged for the commit (terms I explained in the previous blog).

Consider you are in a photoshoot location now, it is like running git init. Once you have written the required code, similar to adjusting to the best location, angles, and poses, just like running git add .

Now, when you have all the perfect details for the picture, it is like making a commit by running a command called git commit -m “message for the commit” . The commit is like a snapshot of the working directory at that point in time, with all the modifications in the working directory.

The git management is structured in such a way that in one place, only the actual code is stored, called blobs; in the other place, the details about that code are stored, like the “hello world” is written in the index.html file, which is called the tree. There is a place that stores the reference to all of this information called a commit. Imagine the picture you clicked, all the pixels captured by the camera are the blob, the details of those pixels where they are stored are trees, and all of it makes the picture, which is a commit.

If the git takes the whole snapshot of the code, then it must be taking so much storage means if x if the storage for one commit is x, then for the second commit it will be 2x. RIght?

But that’s not how it works. Even though every commit is a snapshot, it is not stored twice, it’s references wrt to the changes are stored at the given commit, and it tracks the changes on the fly. It’s like reconstruction of the image from the pixels on the fly, which was captured some time ago or even yesterday or even years ago.

Let’s understand how git uses hashes. It’s like a sticker on the code and these is only generated when add and commit in the working directory. To simplify, it is only generate when you tell the model in the photoshoot to hold the pose or to change the pose and when you click a picture.

Everything in depends on the HEAD and is updated from the the refs/heads/ folder and it contains the heads means it contains the name of the head on whenever we took a snapshot of the code. When you read the reference file, it contains the id which is head commit id.

You can read about the commit details with that id to do that git cat-file -p <commit id> what it contains.

The tree id is made up of the tree folder name first letters and commit id. Where this is tree can be found? It is in the objects/ folder and first letters makes the folder’s name and when you cat (means read) the file (which is basically an id) the output it prints is a blob object which is our compressed code within those gibberish text.