How git works Internally…!
stupid content tracker
Hello Everyone welcome to the continuation part of internal working of git. If you are not read my previous post go through this link and comeback again. If you are already read my previous post and curious to know the internal working of git welcome lets begin.
To see how git works internally lets make new directory and initialize directory with git. If you are not aware of the below commands go back to my previous post there I have explained .
$ mkdir gitdemo
$ cd gitdemo
$ git init
Now the Repository look like below. It contains “.git” directory as usual which then contains subdirectories .I explained each and every file working in my previous post please read and comeback if you are not read.
lets add text file “todo.txt” inside our repository and commit the changes before that lets look inside our “objects” folder whether any objects already their lets look inside it.
As of now there are no objects present inside our “objects” directory .lets now make one commit with message “First Commit”.
Lets switch to git concept what git internally does is it will take the piece of content and generate “SHA-1” key based on content and stores it has key and value pair where key is the “SHA-1” generated and value as content. In real keys as “Filename” value as “File content” lets see that in practical by looking inside “objects” directory.
as you seeing many subdirectories have been created inside “objects” if we carefully look inside anyone of the subdirectories it will look like as I explained above. lets look inside the subdirectory.
As you are seeing above digits are “SHA-1” key generated by git and the content inside is changes that we have made.to reduce the file size git removes unnecessary spaces and stores in the form of blob object. lets deep dive and understand more clear. lets run below command to check the history.
$ git log
above command give us the detail of the commit including commit “SHA-1” keys as shown above. git also generates “SHA-1” key for also commit if we carefully observe inside “objects” folder their contains subdirectory named starting two digit of “SHA-1” key (as above “43”) lets look inside objects directory.
if we look inside the above highlighted subdirectory it contains blob object with name as remaining “SHA-1” key in our case it should look like as below (81af3b29aa7cbdd252da172f74194d1cd1de83) you can cross verify.
As you are seeing it contains blob object with filename as remaining “SHA-1” key let look inside it what does that blob object actually contains by running command.
$ git cat-file <SHA-1 key> -p
Above command will go inside objects and then inside “43” subdirectory and then blob object present inside and it will read the blob object prints the content in console. the above content has author details and another “SHA-1” key inside we can cross verify what actually it contains.
As you are seeing above during commit we have added “todo.txt” that changes have been shown above. If you carefully observe what we have already discussed .git actually manage changes in the form of binary tree in our case the binary tree looks like as shown below.
For simplicity I used starting 5 digit of the “SHA-1” key you can cross verify in your local pc. Lets add some content inside “todo.txt” and make our second commit to get clear understanding.
I added some content inside “todo.txt” and I have made my second commit as commit message “Second Commit” lets run log command and see the history.
as you are seeing above we have 2 commits .lets look into our latest commit and check what inside it.
If you carefully observe our “Second Commit” as extra property named “parent”. as I said git stores objects in the form of binary tree. here parent “SHA-1” key refers to the previous commit “SHA-1” key now you think why we need previous “SHA-1” keys. Here is the answer say for example you made some mistake in latest mistake now you want to go back to previous commit at the time git should know what is my previous commit reason they are storing parent “SHA-1” key and after that same procedure follows as I said above. now our updated binary tree look like as below.