Day 01/13 of Git 101 Series
What Git Actually Is – In-Depth Guide
Concept explanation
git works differently from older version control systems. they record differences between versions like a track changes mode. git doesn’t think in diffs first. it thinks in snapshots. every commit is a full picture of your entire project at that moment.
the smart trick is that git doesn’t duplicate unchanged files. it reuses the same stored content for anything that hasn’t changed. so a snapshot feels “full”, but internally it reuses data. this is why git is fast, efficient, and resistant to tampering. if someone rewrites history, hashes break and the chain exposes the manipulation instantly.
Commands
git init # start a new repository
git add <file> # stage a file for the next snapshot
git commit -m "msg" # create the snapshot with a message
git log # view the chain of snapshots
git show <commit> # inspect a specific snapshot
Example
say your project starts like this:
project/
├── index.html (Welcome)
├── style.css (body { color: blue; })
└── script.js (console.log('hi'))
you run:
git add .
git commit -m "initial"
git stores blobs for each file and a tree describing the folder. imagine hashes like:
index.html → aa12f1
style.css → c3d9b0
script.js → f91ab3
one week later you only change style.css:
git add style.css
git commit -m "changed to red"
git creates a new blob only for the updated style.css and reuses the old blobs for the other files. the snapshot is new, but most of its content is shared with the old one.
another week later you want to see the original state:
git checkout <commit-hash>
the project jumps back instantly because git has the full snapshot, not a set of diffs it needs to replay.
Real-world usecase
In a team, each developer works on a different branch. every branch is just a separate chain of snapshots. when merging, git compares the complete state of each branch and its common ancestor. if there’s a conflict, you see the exact chunks of text that clash. if the merge fails completely, you still have a clean snapshot from before the attempt. nothing is lost.
Under-the-hood explanation
Running git init creates a .git folder. that folder holds all snapshots in a content-addressed database called objects.
when you run git add style.css, git does this:
reads the file content
computes a SHA-1 hash for that content, something like 77c245…
stores the file in .git/objects/77/c245…
records in the index that style.css → blob 77c245
when you run git commit, git freezes everything in the index into a snapshot:
it creates a tree object that maps filenames to blobs
it creates a commit object that points to that tree, the parent commit, the author info, the timestamp, and the message
the hash of this commit becomes the new head of your branch
the chain is secure because every commit hash includes the hash of its parent. change anything in a past commit and every hash after it becomes invalid. the structure enforces honesty by design.
you can read the series of @blogs in here. and i do write a lot in twitter @yswnth