Getting Started with Git — Chapter 1 / 4
Understanding the Git model
Before typing commands, you need to understand how Git works. In this chapter, we'll compare Git to a photographer's notebook. After this chapter, Git will no longer be a black box to you.
The analogy: the photographer's notebook
Throughout this chapter, we'll compare Git to a photographer's notebook. Here are the correspondences:
Your camera
= Working directory (your project folder)
The selection tray
= Staging area (files ready to be saved)
The notebook
= Repository (the history of your saves)
A page in the notebook
= A commit (a complete snapshot of your files)
A bookmark
= A branch (a pointer to a page)
The open page
= HEAD (the page you're currently reading)
Why Git exists
Git was created in 2005 by Linus Torvalds. Linus Torvalds is also the creator of Linux.
He needed a tool to manage code. A tool that works even when thousands of people are working at the same time. A tool that works without a central server.
Before Git, developers used tools like SVN or CVS. These tools needed a central server. If the server went down, nobody could work.
Key term: distributed
Git is distributed. This means every person has a complete copy of the project on their machine. It's like every photographer having their own complete notebook. No internet connection is needed to work.
Important point
Git is not GitHub. Git is the tool that manages versions of your code. GitHub is a website that hosts Git projects. You can use Git without ever going to GitHub.Understand the difference: Git vs GitHub →
Snapshot: the true nature of Git
Key term: snapshot
A snapshot is a complete photo of all your files at a specific moment. In our photographer's notebook, each page is a snapshot. The page shows all the project's photos, not just the new ones.
Many systems store the differences between files. Git works differently: it takes a complete photo at each commit.
Other systems (SVN)
To see the current version, you need to replay all changes from the start.
Git
Commit 1
index.html → "Hello"
Commit 2
index.html → "Hi there"
style.css → "body { margin: 0 }"
Commit 3
index.html → "Welcome"
style.css → "body { margin: 0 }"
footer.html → "Page footer"
Each commit contains all files. Direct access to any version.
If a file hasn't changed, Git doesn't copy it again. It just keeps a link to the previous version. It's fast and doesn't take up much space.
The 3 working zones
Git organizes your work into 3 zones. Understanding these 3 zones is essential to understanding the Git model.
📷
Working Directory
Your project folder
You edit your files here
🗂️
Staging Area
Preparation zone
You choose what to save
📖
Repository
The history
Your permanent saves
It's like our photographer's notebook: you take photos (working directory), you choose which ones to put on the next page (staging area), then you glue the page into the notebook (commit to the repository).
You'll practice these commands in detail in chapter 2.
Git objects
Git stores data as 4 types of objects. Here's how they connect:
commit
a1b2c3d
"Add homepage"
Author: Alice · Feb 14, 2026
tree
d4e5f6a
List of project files
blob
index.html
"<h1>Hello</h1>"
blob
style.css
"body { ... }"
blob — the content of a file
A blob contains the raw content of a file. It does not contain the file name. It's like the content of a letter without the envelope.
tree — a folder
A tree represents a folder. It contains a list of files (blobs) and sub-folders (other trees). It's like a table of contents in a book.
commit — a save point
A commit is a complete snapshot of your project. It contains:
- - A link to a tree (the project content)
- - A message (what you did)
- - An author and a date
- - One or more parents (the previous commits)
tag — a label
A tag is a name given to a specific commit. For example: v1.0 or v2.3. It's like putting a bookmark in the notebook.
How Git actually stores data
Here's what really happens when you create a file and commit it:
# You create a file and commit it
$ echo "Hello" > hello.txt
$ git add hello.txt
$ git commit -m "Add hello"
# Git created 3 objects:
# 1. A blob (the file content)
$ git cat-file -p ce013
Hello
# 2. A tree (the list of files)
$ git cat-file -p 8a9f2
100644 blob ce013 hello.txt
# 3. A commit (the snapshot + metadata)
$ git cat-file -p a1b2c
tree 8a9f2
author Alice 1707900000
Add hello
You don't need to remember these commands. The key point is that Git stores connected objects: the commit points to a tree, the tree points to blobs.
The hash: an object's identity card
Key term: SHA hash
A hash is a unique code calculated from the content of an object. It's like a unique barcode on each page of the notebook. Two different contents always give two different hashes.
Every Git object has a unique 40-character hash. In practice, we often use just the first 7.
$ git log --oneline
a1b2c3d Add homepage
e4f5g6h Initial commit
The hash guarantees that the data is intact. If a single character changes in a file, the hash will be completely different. It's impossible to modify the history without Git detecting it.
Branches: bookmarks
Key term: branch
A branch is a name that points to a commit. In our notebook, it's a bookmark. The bookmark says: "I'm on this page". When you add a new page, the bookmark moves forward.
A branch is not a copy of the code. It's just a small file containing the hash of a commit. Creating a branch is instant.
# Two bookmarks in the notebook
main → a1b2c3d (page 3)
feature → e4f5g6h (page 5)
HEAD → main (you're reading the page at the "main" bookmark)
The branch graph:
→ C → D → E (feature)
/
A → B → C (main, HEAD)
Concretely, Git stores each branch as a file in the .git/refs/heads/ folder:
$ cat .git/refs/heads/main
a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0
# That's it. A 40-character file.
You'll create and merge branches in chapter 3.
HEAD: the open page
Key term: HEAD
HEAD is a pointer that says "you are here". In our notebook, it's the page you've opened. Usually, HEAD points to a branch (a bookmark).
When you make a new commit, the branch moves forward. And HEAD follows the branch.
# Before the commit:
HEAD → main → a1b2c3d
# After the commit:
HEAD → main → f7a8b9c → a1b2c3d
Sometimes, HEAD can be "detached" (detached HEAD). This means HEAD points directly to a commit, without going through a branch. It's useful for looking at an old commit. But be careful: if you make commits in this state, they can be lost (no bookmark points to them).
The Git graph
Key term: graph (DAG)
Git's history forms a graph. Each commit points to its parent (the previous commit). It's like a family tree: each child knows its parents.
You can see the graph with this command:
$ git log --graph --oneline --all
* f7a8b9c (HEAD → main) Merge branch 'feature'
|\
| * d4e5f6a (feature) Add feature
|/
* a1b2c3d Initial commit
Local vs Remote
Your Git repository is on your machine. This is your local repository.
A remote repository is a copy of the project on a server. For example on GitHub, GitLab or Bitbucket.
In our analogy, it's like your colleague having their own photographer's notebook. You can send pages to each other:
git push
You send your new pages to the shared notebook
git pull
You get the new pages from the shared notebook
git push: sending your commits
When you have made one or more commits locally, you can send them to the remote repository with git push.
$ git push
# Send your local commits to the remote repository
# Other team members will be able to see your changes
git pull: getting the latest changes
When other people have pushed commits to the remote repository, you can get them with git pull. This command does two things: it downloads the new commits (fetch) and then merges them into your branch (merge).
$ git pull
# Fetch remote commits and merge them into your branch
remote: Counting objects: 3, done.
From github.com:user/project
a1b2c3d..f4e5d6a main → origin/main
Updating a1b2c3d..f4e5d6a
Fast-forward
readme.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Good practice
Run git pull before you start working. This ensures you have the latest version of the project. You will avoid unnecessary conflicts.
The key takeaway: you can work without an internet connection. You sync whenever you want with push and pull.
Summary
Here's how all the concepts in this chapter connect:
You edit files in the Working Directory
You prepare files in the Staging Area
Git creates a commit (snapshot) in the Repository
Objects (blob, tree, commit) identified by SHA hashes
Branches (pointers) with one active via HEAD
A graph (DAG) that is the complete project history
Common mistakes
- ●Confusing Git and GitHub. Git is the tool. GitHub is a website.
- ●Thinking a commit only saves the changes. No, it's a complete photo (snapshot).
- ●Thinking branches are copies of the code. They are just pointers (bookmarks).
- ●Not understanding that HEAD can be detached. If you commit without a branch, it can be lost.
- ●Forgetting the staging area. Files aren't saved until you run git add then git commit.
Further reading
Test your knowledge
Before moving on to the exercises, check that you understood the concepts. Click on the answer that seems correct.
Quiz — Chapter 1
1. A Git blob contains...
2. How does Git save your files?
3. What is a Git branch?
4. When HEAD is detached and you make a commit...
Going further
This chapter covers the fundamentals of the Git model. If you want to go deeper, here are some paths:
- ●SHA-1 vs SHA-256: Git used SHA-1 to calculate hashes. It is gradually migrating to SHA-256, which is more secure. The mechanism remains identical.
- ●Garbage collection: Git automatically cleans up objects that are no longer referenced by any branch or tag. That's why a commit in "detached HEAD" can be lost.
- ●Pro Git: the free reference book on Git. Available online at git-scm.com/book.
- ●Official documentation: git-scm.com/doc for the complete reference of all Git commands.
Your feedback matters
Help us improve this course by sharing your thoughts.