What is .git, Anyway?

When you execute git init in your project initially, Git creates a hidden .git directory inside the working directory.

Git is like a super-smart filing cabinet that remembers every version of every file you have ever committed. And the .git folder is where that filing cabinet lives.

Now .git is, like Git’s brain, almost all the git’s shenanigans happens here. Git operates as a content-addressable filesystem with a version control interface built on top of it.

Inside .git

After initializing a new repository, Git creates several key components:

• HEAD : A reference to the current branch, like a bookmark.

• objects/ : The directory, which is the actual database where Git stores all the files upon commits.

• refs/ : Stores pointers to commits e.g. branches, tags etc.

• config : Configuration directory containing Git settings specific to your project.

• index : The staging area, where tracked files are stored. More of this is discussed later.

• hooks/ : Scripts that run automatically on Git events.

Three Musketeers: Blob, Tree and Commit

Git uses three types of objects to track your project.

1. Blob : A blob stores the content of your files. Not filenames, not directory structures; just pure content. Think of blobs as actual “stuff”.

2. Tree : Trees organize blobs by storing filenames and directory structures. A tree is like a directory that points to blobs (files) and other trees (sub-directories).

3. Commit : A commit object references a tree and includes metadata like author, timestamp and parent commits. It is the snapshot of your entire project at a specific point in time.

What Really happens during git add and git commit ?

Let me dissect what happens to these commands you use everyday.

Running git add

1. Git calculates a SHA-1 hash of your file’s content

2. The file is compressed and stored as a blob in the objects directory

3. Index (Staging area) is updated with a reference to this blob

Git stores each object in a sub-directory named with the first two characters of its hash, with the remaining 38 characters as the filename.

Running git commit

1. Creates a tree object from the staging area

2. It creates a commit object pointing to that tree

3. The commit includes your message, author info and timestamp

4. Current branch pointer moves to this new commit

Essentially, git add stores blobs for changed files and updates the index, while git commit creates tree and commit objects.

The Secret Sauce: SHA-1 Hashes

Git uses SHA-1 hashes as unique identifiers for all objects. Every file, every commit gets a 40-character fingerprint like b69cf9v9f8d9xcv9fdd9v8bf99vfuhrixo76f908.

Why this matters?

Integrity. Even one-bit change changes the hash completely.

Identical files gets the same hash, enforcing deduplication.

git can quickly check if the content exists by looking up its hash.

Summary of it

In Git, everything is content-addressed, where files are stored by their content’s hash.

Each commit is a snapshot, not only diffs.

Branches just point to commits, making them lightweight and fast.

Git is basically a Directed Acyclic Graph (DAG), commits link to their parent commits.

Conclusion

Git is a content-addressable filesystem where blobs store file contents, trees store directory structures, and commits tie everything together with metadata. SHA-1 hashes ensure integrity, and the .git directory is where all this magic lives.

project, project_modified, project_sam, project_latest, project_final

Then you already have some idea what this blog is about.

If you did not get it, the next section is especially for you.

Pendrive: One Man Army

I learned about the importance of Version Control in a very early age.

Year 2009, my uncle was in his final year in BTech. He had a few pen-drives in his collection, of various sizes. Some of ‘em contained media, some had important project files. I remembered he had a friend with whom he used to share one of his pen-drive with. It was a fancy looking one, 16GB stick. He explicitly forbed to touch that pen-drive out of all.

So one day, I touched and took the pen-drive and went to a gaming parlor to “load” the new GTA IV to it.

The transfer started, after a while I got an error of insufficient storage. Now you get where this is going.

I saw a file named “BMS_final.zip”, and I deleted it. Thank God I did not know shift + del back then.

My uncle got back his project file inside the recycle bin of a random PC inside the game parlor, but that was not enough to stop myself from getting smacked.

This story highlighted a grave issue of using Pendrives, a single point of failure.

And I got to know the other issues when I had to use it myself.

Me and my team was building a website. Areej works on the homepage, copies her changes to a pendrive, and emails it to Ankit. Ankit makes his updates, but his pendrive corrupts. Meanwhile, Priyanshu has been working on the same files for two days, unaware that Areej already modified them. When Priyanshu finally shares his version, Areej’s changes vanish into the void.

The pendrive, like a baton in a relay race, hurt parallel programming.

An alternative approach was by mail, but it did not fix versioning problems.

The problems were endless. Someone would overwrite someone else's work. Critical changes would disappear. Nobody knew who changed what, when, or why. If you needed to revert to last week's working version? Good luck finding it among 47 folders named variations of "final."

Collaboration Catastrophe

The real nightmare began when multiple developers touched the same file.

Imagine three people editing a recipe simultaneously, each with their own copy. One adds salt, another removes sugar, and the third changes the oven temperature. When you try to combine their work, you end up with a recipe that's simultaneously too salty, missing sugar, and has conflicting cooking instructions.

Developing software this way was just not inconvenient, it was counterproductive. Builds broke, bugs that resolved previously re-appeared in someone else’s overwrite, there was no history on who changed what, teams spent more time on managing files rather than actual development.

The Silent Guardian: Version Control

Version control systems emerged from this chaos as a fundamental answer: what if every change was tracked, every developer could work simultaneously, and you could travel back in time to any previous state of your code?

Modern Version Control Systems like Git became a watchful productivity protector and versioning moderator.

They track every changes, by a complete history of who, when, where and why.

They embrace collaboration where multiple developers can modify the same file without overwriting, or overwriting under developer’s sane control and supervision.

They provide instant rollback to a previous state if something breaks on the current state.

Code Reviews became easier than ever before merging a change into the main codebase.

VCS is not optional

Version Control is an integral part of Software Development. Even a solo developer uses it, because the real enemy is not other developers overwriting your code, it's forgetting what worked, losing track of changes, and having no safety net when things break.

Developers who are getting started in today’s era may not face the pendrive problem, or they may face it like us; in either case this blog is for them, to remind how Version Control transformed development from a chaotic relay race to a symphony where every note is preserved, every musician can be heard, and you can always replay the part that worked.

I was working on a semester project based on a Python stack. My teammates handled dataset processing and model training, while I worked on the Streamlit UI. Our workflow was on our local machines, the backend team would send me the updated file, and I would build the UI to use it. We worked in it for a week then submitted to our mentor for review.

Everything went smooth before the mentor review.

We got our project feedback, and I realized that was just version 1.0. Now the project needs new features, bug fixes, and potential refactoring.

And my backend storage looked like this:

Get the problem here? The names were ambiguous, files were duplicated, and no one knew which version was actually “correct.” Every change meant another folder, more guessing, and more risk.

So I thought how can we keep track of these files, at a single place, maybe I can use GitHub!

I created a repository, uploaded the files, and thought I was done. When something changed, I planned to upload the modified files again, have a nice day. After some while, a teammate summed it up perfectly:

“bruh just use Google Drive then”. I got humbled and curious. I was just thinking of using GitHub like Google Drive. Then what makes them different? It’s Git.

What is Git?

Git is like a supervisor, looking over your work and taking pictures of changes you made on it, so you can keep track of it, in an organized and efficient way. Formally, Git is a Version Control System (VCS) which helps managing our projects in a versioned manner.

Attention to my phrase “taking pictures” here, that’s what differentiates Git from other VCSs. Git tracks the changes of every file in the directory by taking snapshots of it.

Also, everything git does is totally local by default. Services like GitHub, GitLab, BitBucket etc is just git being run on a server remotely. You can create your own git server by hosting it on any VPS (Virtual Private Server).

Why Git exists?

thought of articulating some points efficiently, but I already shared my lore, and ChatGPT shared some great points:

Core Concepts

• Repository: A repository is the working directory you want Git to track, along with the .git folder, which is a database tracking the changes and metadata about the directory. So Repository: Working Directory + .git

• Commit: You created a file, made some changes in an existing file, and want to finalize those changes to the next version of the project. That’s when you perform Commit, to finalize, locally.

• Branch: Branch is what enabled me and my teammate working on our respective parts and features at the same time, and merge them to the main ones after it got finished.

  

• HEAD: HEAD is a reference to the latest commit in your working directory in the current branch.

  

Staging Area: The staging area is a checkpoint between your working directory and the repository. It contains only the specific changes you’ve deliberately selected to be included in the next commit.

Essential Commands to get started

• Birth of a Project (git init): Initializes git for the working directory where the command is executed. This command makes a .git directory, initializes the directory metadata and a database. This should be the first command to start using git for your project.

• Selective Addition (git add): Adds the content of added or modified files into the staging area a.k.a. the index. This is the first step towards deciding which makes it to the commit history.

    git add <file_path>
    git add .            # to add all untracked files in the staging area
  

• Making History Permanent (git commit): After the desired changes are made in the working directory, this command adds a new commit containing the current contents of the index (staging area) and the given log message describing the changes.

    git commit -m "commit message"
    git commit -am "commit message"    # add modified files into the staging area and commit
  

  

• Awareness before action (git status): This command shows the files which have been added/deleted or modified since the latest commit. It shows the path of the tracked files (exists in the staging area), and files that have been untracked as well

• Seeing the Past (git log): Logs the commit history in the current branch, along with commit hash, author, date and time, message.

  

• Parallel Timelines (git branch): A branch in Git is a lightweight pointer to a specific version of your project that lets you work on changes in isolation without affecting the main codebase.

  In my earlier project setup, creating a new feature meant creating a new folder. With Git, I can create a branch instead.

  Instead of this mess

    backend/
    backend_25jun/
    backend_final/
    backend_final_fixed/
  

  I can do better:

•       git branch feat/report
        git switch feat/report
  

  Now this is sane and safe, does not tamper the main branch which is currently functional

• Understanding Change (git diff): Before Git, you found differences by opening two folders and eyeballing files. That doesn’t scale, and it misses subtle bugs.

  git diff shows exact line-by-line difference between the working directory and the staging area or the staging area and the last commit.

  

  It helps finding accidental edits, un-removed debug messages.

git status tells something has changed, git diff shows what changed across commits.

• Undoing Mistakes:

  • git reset: git reset moves the current branch pointer backward to an earlier commit. It is like “pretend this commit never happened”.

    Git reset only makes sense if the damage is only local. git reset after pushing it remotely is as useful as starting singing after farting in public. The damage is already done.

  • git revert: Reverting is undoing without hiding or rewriting the history. git revert adds a new commit, which undoes the changes made in the last commit and performs it as a new commit.

    revert is the safest option after the changes have been pushed remotely.

• Rewriting History, Responsibly (git rebase): If you are going to stick in this game for long, you are definitely going to make some bunch of small, trivial commits which was necessary for the project, but looks messy while auditing or tracking history.

  git rebase just solves that problem by addressing those commits and organizes them into fewer ones, without changing the actual files in the working directory.

  Another use-case of git rebase is integrating and reorganizing commit history from another branch.

• Leaving the Machine (git push): To collaborate and easy access of your repository, it is convenient to serve your project remotely. git push sends your commits to a remote repository so others can access them.

  Now you get the idea of Git and GitHub.

Summary

Another point I want to add is: Git is a free and open-source tool created by Linus Torvalds for managing Linux, now it is being managed by the community, for the community. And GitHub is another proprietary piece of Git hosting server with an UI, by Microsoft (what a time to live). Git is a Version Control System, GitHub is a hosting platform.

These commands discussed are enough to get started controlling your project using Git. To learn in-depth, it is always recommended to read the official docs, it IS the gold-standard.

Software development is subjective, it is in it’s nature things will break, and eventually will get fixed. Git gives you the power to attempt your crazy ideas without breaking something which was working few minutes ago.