Inside Git: How it Works and the Role of the .git Folder
Sneak peek into the .git/ folder
If you open the .git folder, you will see many files and folders.
HEAD and index are files, rest all are folders.
Now to understand Git properly, we just need to understand what happens internally when we use the main commands like git add, git commit, git diff, git log, and git status.
The moment we run the “git init” command, the “.git/” folder gets created, it basically contains lots of folders and files inside it, but since this folder is hidden, we will see it only when we run the “ls -a” commmand as it lists all the hidden folders.
Now what all folders and files it contains inside let us see.
HEAD and index are files , rest all are folders
What happens when we run git add?
When we run the git add command to stage the code or in easy language to take the snapshot of the code, a blob object is created in the blob objects file which is present inside the objects folder.
This blob object file has a hash associated to it, so irrespective of the number of blob object files are getting created, each blob object inside each blob object file is then hashed ie generates a hash id for the blob object and this hash id is uniquely associated to that blob object only.
These hashes of each blob object are stored in the index file, so index file keeps and tracks the hashes associated with each blob object.
However, note that the index file does not create a linked list. It merely holds the hashes of current staged blobs, enabling git to efficiently compare the working directory and staged snapshots.
What happens when we run git commit -m?
Now when we run the git commit -m command, git creates a commit object which contains the meta data like author, date, message and most importantly it references the tree of blobs currently in our index.
This commit itself is given a unique hash and each subsequent commit stores the hash of the previous commit, creating a linked list.
Commit object is stored in Objects and has a tree hash of commited files which contains references of individual blob hashes just like index file tracks the hashes of staged.
Role of HEAD and references
The head file contains the name of the branch while the reference file contains the reference.
So basically HEAD file contains/ stores the pointer that indicates our current branch, and HEAD file gives the reference which contains the hash of the commit which in our case is reference file itself.
In simple terms, the HEAD file contains the Branch upon which we are working upon and then contains the reference of the file which is containing the hashes of the commits done in that particular branch.
And the reference file tracks the commit hashes.
So basically this structure helps git to navigate and keep the track record easily.
Commands and how they use this workflow internally
Now the commands that internally utilises these folders and files that we mentioned and follows the above mentioned workflow internally are like this:
If we run git diff HEAD in that case it basically shows us the difference between the working directory and the local repo
If we just run the git diff and put in the commits id then it gives us the difference between the two different commits
If we run git diff --staged it gives us the difference between the staging area and the local repo
If we run the git log it just gives the log of commits that is message hash id etc of only commits so git log always deals with the commits right
git status basically gives us the relationship between the working directory and the staging area
