Learn Git - Core Concepts & Main Git Architecture

#Introduction

In episode 1 we understood why Git exists: replacing manual archives and centralized VCS with a system that is fast, offline-capable, and guarantees data integrity. Now we dissect how Git works on the inside.

This architectural understanding is not empty theory. All the commands you will use — git add, git commit, git stash, git restore — work by moving files between different areas. Once you understand the areas, the behavior of every command becomes logical and predictable.

#The Three Main Git Areas (Three States)

Every file in a Git repository always lives in one of the following three areas.

#Working Directory

The area where you edit files — the project folder you see and open in your editor. Changes you just made here are not yet "known" to Git.

#Staging Area (Index)

The intermediate area that holds a snapshot of the changes ready to be committed. This is where you arrange what goes into the next commit. The Staging Area is also called the Index and is represented by the index file inside the .git folder.

#Repository (.git)

The area for permanent storage of the entire commit history — Git's database inside the hidden .git folder. Once a commit is made, its data lives here and becomes part of the history.

#File Flow Between Areas

File status across the three areas

git status --short
 M README.md
A  fitur-baru.js
?? catatan.txt

How to read the status above:

M README.md — the file changed in the working directory, not yet staged.
A fitur-baru.js — the file is in the staging area, ready to be committed.
?? catatan.txt — a new file Git has never seen (untracked).

Commands for moving between areas:

Working → Staging: git add <file>
Staging → Repository: git commit -m "pesan"
Staging → Working: git restore --staged <file>
Repository → Working: git restore <file>

#Bonus: The Stash Area

Stash is a "temporary storage locker" outside the three main areas. Use it when you have to switch context suddenly (e.g. switch branches) while your work is not finished. The git stash command saves your changes temporarily and cleans the working directory; git stash pop brings them back. We will cover the full details in episode 15.

#Under the Hood: Snapshots, Not Deltas

This is one of the things that most distinguishes Git from other VCSs. Subversion stores deltas — records of differences between versions. Git stores snapshots — the complete state of all project files at the moment of a commit.

If no files changed between two commits, Git does not store a duplicate copy — it simply points back to the previous snapshot. The result: restoring an old commit is as easy as pointing at a snapshot, without needing to "replay deltas" one by one.

#Git's Basic Objects

All Git data is stored as objects in the database inside the .git/objects folder. There are four types you must know.

#Blob

A Blob (Binary Large Object) is the pure content of a file — without a filename and without metadata. Two different files with identical content share the same blob; this is the basis of Git's storage deduplication.

#Tree

A Tree represents a directory: a list of filenames mapped to blobs, or subdirectories represented by other trees. This is what connects blobs into a real folder structure.

#Commit

A Commit is the most important object: it stores metadata — author, committer, timestamp, message — along with a pointer to the tree representing the snapshot state at that time, plus a pointer to the parent commit (parent). This chain of pointers is what forms history.

Anatomy of a commit

commit 3f2a1b0c
author  Arman Dwi Pangestu <arman@kalian.com>
message  feat: tambah halaman login
tree  b8d4e7f1
parent  9c4a2d6e

#Annotated Tag

A Tag is a label for a specific commit, commonly used to mark release versions (v1.2.3). An annotated tag stores additional metadata — message and signer — and becomes a Git object itself, unlike a lightweight tag which is just a plain pointer without metadata. Details in episode 20.

#Hashes as Unique IDs

Every Git object — blob, tree, commit, tag — is given an identity in the form of a cryptographic hash of its content, using SHA-1 (40 hex characters) and now beginning to move to SHA-256 (64 characters).

The hash serves a dual purpose:

Unique ID — objects are referenced and looked up by their hash (e.g. a1b2c3d).
Integrity guarantee — it is the object's content that gets hashed; change a single character, and the hash changes completely, letting Git immediately detect corruption or tampering.

Computing the hash of a file's content

echo "selamat datang" > README.md
git hash-object README.md
f2c3d4e5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1

Tip

Try running git hash-object <file> on the same file twice — the hash is always the same. This is the principle of deduplication: identical files, wherever they are located, are stored only once by Git.

#Closing

Episode 2 recap:

Three areas: working directory (edit), staging area (arrange), repository (permanent storage), plus stash as temporary storage.
Git stores snapshots, not deltas — efficient and fast to restore.
Basic objects: blob (file content), tree (folder structure), commit (history), and annotated tag.
SHA-1 / SHA-256 hashes act as both IDs and integrity safeguards.

In episode 3 we start real hands-on practice: initializing a repository with git init, reading file status with git status, marking untracked and staged files, and setting up .gitignore. You already have a solid foundation — now it is time to get your hands typing. See you there!