Understanding the Git model

Before diving into technical vocabulary, here is an analogy that will guide you throughout this chapter. Imagine a photographer documenting a construction project:

• ●The camera = the Working Directory (your work folder)
• ●The selection tray = the Staging Area (you choose which photos to keep)
• ●The photo notebook = the Repository (the complete album, the history)
• ●A page in the notebook = a Commit (a dated photo with a caption)
• ●A bookmark = a Branch (a marker placed on a page)
• ●The open page = HEAD (the page you are currently looking at)

In 2005, Linus Torvalds (the creator of Linux) needed a tool to manage the Linux kernel source code. Existing tools like SVN or CVS were centralized: a single server held the history, and if the server went down, everything was lost.

Linus created Git with clear goals: speed, distributed design, support for non-linear development (branches), and the ability to handle very large projects like the Linux kernel.

Most older versioning systems (like SVN) store differences (deltas): "in file X, line 3 was modified". Git works differently: at each commit, Git takes a complete snapshot of all the project files.

SVN stores differences between versions. Git stores complete snapshots of the project at each commit.

Git organizes your work into 3 distinct zones. Understanding these zones is fundamental to mastering Git:

• ●Working Directory — your work folder, where you edit your files
• ●Staging Area (Index) — the preparation zone, where you choose what goes into the next commit
• ●Repository (.git) — the complete project history (the commits)

Under the hood, Git uses 4 types of objects to store everything:

• ●Blob — the raw content of a file (without the file name)
• ●Tree — a directory: a list of blobs and other trees with their names
• ●Commit — a snapshot: points to a tree + contains a message, an author, a date, and a link to the parent commit(s)
• ●Tag — a named label placed on a commit (e.g., v1.0)

Visually, a commit points to a root tree, which itself points to blobs (files) and other trees (subdirectories). It is a tree-like structure.

Let's see concretely how Git transforms your files into objects:

# Git creates a blob with the content "Hello"

[main abc1234] Add hello.txt
 1 file changed, 1 insertion(+)

You can inspect the created objects with git cat-file:

Hello

100644 blob ce013625030ba8dba906f756967f9e9ca394464a    hello.txt

tree 4b825dc642cb6eb9a060e54bf899d69f7b0fbb15
author Dev <dev@example.com> 1234567890 +0100
committer Dev <dev@example.com> 1234567890 +0100

Add hello.txt

Every Git object (blob, tree, commit, tag) is identified by a SHA hash. It's like a unique barcode: two different contents always produce two different hashes.

a1b2c3d Add hello.txt
e4f5g6h Initialize project

The first 7 characters are usually enough to uniquely identify a commit. The hash guarantees integrity: if a file is modified, its hash changes, and Git detects it immediately.

A branch is just a bookmark placed on a commit. Creating a branch doesn't copy anything — it's instant and takes only 41 bytes on disk (the commit hash + a newline).

Visually, branches can be represented as labels placed on commits in the graph. The main branch and the feature branch each point to a commit. HEAD indicates the active branch.

a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

That's it! A branch is literally a 40-character file containing the hash of a commit.

When you make a commit, HEAD moves forward with the branch. Before the commit, HEAD points to main which points to commit A. After the commit, main advances to commit B, and HEAD follows.

Commits form a graph: each commit points to its parent (the previous commit). Branches create forks, merges bring them back together. You can visualize the graph with:

* d4e5f6g (HEAD -> feature) Add the sidebar
* c3d4e5f Add the header
| * b2c3d4e (main) Fix the footer
|/
* a1b2c3d Initialize project

So far, everything is local (on your machine). To collaborate, you sync with a remote repository:

# Sends your local commits to the remote repository

remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
From github.com:user/repo
   a1b2c3d..e4f5g6h  main -> origin/main
Updating a1b2c3d..e4f5g6h
Fast-forward
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

git pull is actually a shortcut for git fetch (retrieve remote commits) followed by git merge (merge them with your local commits).

• ●Confusing Git and GitHub — Git is the tool, GitHub is a platform that uses Git
• ●Believing a commit stores differences — a commit is a complete snapshot of the project
• ●Thinking branches are copies — a branch is a simple pointer (40 characters)
• ●Being afraid of DETACHED HEAD — it's not an error, it's just HEAD pointing directly to a commit instead of a branch
• ●Ignoring the Staging Area — it exists to let you choose precisely what you commit

• ●Git Glossary — all terms explained simply
• ●Git vs GitHub — understand the difference in detail
• ●Why learn Git — the concrete reasons
• ●Git for beginners — step-by-step guide

• ●SHA-1 vs SHA-256 — Git is gradually migrating to SHA-256 for better security
• ●Garbage collection — Git automatically cleans up orphaned objects with git gc
• ●Pro Git book — the free reference book (git-scm.com/book)
• ●Official documentation — git-scm.com/docs

Before moving on, check that you understood the concepts. Click the answer that looks right.