1. What Is a Repository?

A repository (or "repo") is the complete history of your project, stored as a database of every change ever made. It is not just the current files. It is every version of every file, every commit message, every branch, and every tag, all packed into a hidden .git directory at the root of your project.

The .git Directory

When you run git init, Git creates a .git folder. This single directory contains everything Git needs: the object database (blobs, trees, commits), references (branches, tags), configuration, and hooks. Your working directory is just the latest checkout. The repository lives inside .git.

$ mkdir my-project && cd my-project
$ git init
Initialized empty Git repository in /home/user/my-project/.git/

$ ls -la .git/
-rw-r--r--  HEAD          # Points to the current branch
-rw-r--r--  config        # Repository-level configuration
drwxr-xr-x  objects/      # The object database (commits, trees, blobs)
drwxr-xr-x  refs/         # Branch and tag pointers
drwxr-xr-x  hooks/        # Scripts triggered by Git events

Local vs Remote Repositories

Every Git repository is a full copy of the entire history. When you clone a repository from GitHub, you get everything: every commit, every branch, every tag. Your local repository is not a thin client pointing at a server. It is a complete, independent copy. This is what makes Git a distributed version control system.

2. Commits: Snapshots, Not Diffs

This is the most important mental shift for understanding Git. Most version control systems store changes as diffs: the difference between one version and the next. Git does not do this. Git stores snapshots: a complete picture of every file at the moment you commit.

The Snapshot Model

When you make a commit, Git takes a snapshot of every tracked file in your project. If a file has not changed since the last commit, Git does not store a duplicate. Instead, it stores a pointer to the previous identical file. This makes Git extremely efficient while maintaining the conceptual simplicity of "every commit is a complete snapshot."

# Delta-based systems (SVN, CVS):
# Commit 1: [Full file]
# Commit 2: [Diff from commit 1]
# Commit 3: [Diff from commit 2]
# To reconstruct commit 3, apply all diffs sequentially.

# Snapshot-based system (Git):
# Commit 1: [Snapshot: fileA-v1, fileB-v1, fileC-v1]
# Commit 2: [Snapshot: fileA-v2, fileB-v1, fileC-v1]  (fileB, fileC are pointers)
# Commit 3: [Snapshot: fileA-v2, fileB-v2, fileC-v1]  (fileA, fileC are pointers)
# To reconstruct commit 3, just read the snapshot. No replay needed.

Anatomy of a Commit

Every commit in Git contains four pieces of information: a pointer to the snapshot (a tree object), the author and committer metadata, the commit message, and pointers to parent commits. The very first commit has no parent. Every subsequent commit points back to the commit that came before it, forming a chain.

$ git cat-file -p HEAD
tree 4b825dc642cb6eb9a060e54bf899d15a4f3f7e2a
parent 8a3b5e7f1c2d4e6a8b0c1d2e3f4a5b6c7d8e9f0a
author Jane Developer <[email protected]> 1710864000 -0500
committer Jane Developer <[email protected]> 1710864000 -0500

Add user authentication module

# tree     -> Points to the snapshot of all files
# parent   -> Points to the previous commit (the chain)
# author   -> Who wrote the change
# committer -> Who applied the change (can differ in rebases)
# message  -> Human-readable description of why

SHA-1 Hashes: The Commit ID

Every commit is identified by a 40-character SHA-1 hash, computed from the commit's content (tree, parent, author, message). This means the commit ID is a fingerprint of its entire content. If any part of a commit changes, its hash changes. This gives Git built-in integrity checking: if a commit's hash matches, its content is guaranteed to be exactly what was stored.

3. Branches: Parallel Timelines

A branch in Git is not a copy of your code. It is a lightweight, movable pointer to a specific commit. That is it. A branch is a small file containing a 40-character commit hash (plus a newline). Creating a branch does not duplicate any files. It just creates a new pointer.

How Branches Work

When you create a branch, Git creates a new reference that points to the current commit. When you make a new commit on that branch, the pointer moves forward to the new commit. The other branches stay where they are. This is what creates the illusion of parallel timelines: different branches point to different commits in the same history graph.

# Create a new branch — this just creates a pointer
$ git branch feature-login
$ cat .git/refs/heads/feature-login
a1b2c3d4e5f6...  # Same commit hash as main

# Switch to the branch
$ git checkout feature-login

# Make a commit — the feature-login pointer moves forward
$ echo "login code" > login.py
$ git add login.py && git commit -m "Add login module"

# Now feature-login points to the new commit
# main still points to the old commit
$ cat .git/refs/heads/main
a1b2c3d4e5f6...  # Has not moved

$ cat .git/refs/heads/feature-login
b2c3d4e5f6a7...  # Moved forward to the new commit

HEAD: Your Current Position

HEAD is a special reference that tells Git which branch you are currently on. When you switch branches with git checkout or git switch, you are moving HEAD to point to a different branch. HEAD usually points to a branch name, which in turn points to a commit.

$ cat .git/HEAD
ref: refs/heads/main          # HEAD points to main

$ git checkout feature-login
$ cat .git/HEAD
ref: refs/heads/feature-login  # HEAD now points to feature-login

Why Branches Are Powerful

Because branches are just pointers, they are instant to create and cost almost nothing. This changes how you work. In older systems where branching meant copying the entire codebase, developers avoided branches. In Git, you can create a branch for every bug fix, every feature, every experiment. If it does not work out, you delete the pointer. The commits get garbage-collected eventually. No harm done.

4. Merging: Reuniting Timelines

If branches are parallel timelines, merging is the act of bringing those timelines back together. When you merge branch B into branch A, Git combines the changes from both branches into a single result.

Fast-Forward Merge

If the target branch has not diverged (no new commits since the branch was created), Git simply moves the pointer forward. No new commit is created. This is called a fast-forward merge because Git just "fast-forwards" the pointer along the existing commit chain.

# Before merge:
# main:          A --- B
# feature-login: A --- B --- C --- D

$ git checkout main
$ git merge feature-login

# After merge (fast-forward):
# main:          A --- B --- C --- D  (pointer moved forward)
# No new commit created. main just caught up.

Three-Way Merge

If both branches have new commits since they diverged, Git cannot fast-forward. Instead, it performs a three-way merge: it finds the common ancestor (the merge base), compares both branches against it, and creates a new merge commit that has two parents.

# Before merge:
# main:    A --- B --- E --- F
# feature: A --- B --- C --- D

$ git checkout main
$ git merge feature

# After merge:
# main:    A --- B --- E --- F --- M  (merge commit)
#                 \              /
#                  C --- D -----
# M has two parents: F and D

Merge Conflicts

When Git performs a three-way merge and both branches have changed the same lines in the same file, Git cannot automatically decide which version to keep. This is a merge conflict. Git pauses the merge, marks the conflicting sections in the file, and asks you to resolve them manually.

# Git marks conflicts in the file:
<<<<<<< HEAD
def authenticate(user):
    return check_password(user)
=======
def authenticate(user):
    return verify_credentials(user)
>>>>>>> feature-login

# Above ======= is YOUR branch (HEAD)
# Below ======= is the INCOMING branch
# You manually choose the correct version, remove the markers, then:
$ git add auth.py
$ git commit  # Completes the merge

5. Tags: Named Bookmarks

A tag is a reference that points to a specific commit and never moves. While branches are movable pointers that advance with each new commit, tags are permanent markers. They are used to label important points in history, most commonly release versions.

Lightweight vs Annotated Tags

Git supports two types of tags. A lightweight tag is just a pointer to a commit, like a branch that never moves. An annotated tag is a full Git object with its own metadata: tagger name, date, and a message. Annotated tags are recommended for releases because they carry additional context.

# Lightweight tag: just a pointer
$ git tag v1.0.0

# Annotated tag: a full object with metadata
$ git tag -a v1.0.0 -m "Release version 1.0.0 - initial stable release"

# View tag details
$ git show v1.0.0
tag v1.0.0
Tagger: Jane Developer <[email protected]>
Date:   Mon Mar 18 2026 10:30:00 -0500

Release version 1.0.0 - initial stable release

commit a1b2c3d4e5f6...

6. The DAG: Git's Mental Model

All of Git's structures, commits, branches, merges, and tags, form a Directed Acyclic Graph (DAG). Understanding the DAG is the key to understanding every Git operation.

What Is a DAG?

Directed means each edge has a direction: commits point to their parents (backward in time). Acyclic means there are no loops: you can never follow parent pointers and end up back where you started. Graph means it is a collection of nodes (commits) connected by edges (parent pointers).

# A simple DAG with branches and a merge:
#
#        main
#          |
#          v
# A --- B --- E --- F --- M  (merge commit)
#          \             /
#           C --- D ----
#                 ^
#                 |
#              feature
#
# Arrows point from child to parent (backward in time)
# M has two parents: F and D
# Branches (main, feature) are just labels on specific nodes

$ git log --oneline --graph --all
*   f3a2b1c (HEAD -> main) Merge branch 'feature'
|\
| * d4e5f6a (feature) Add search functionality
| * c3d4e5f Implement basic query parser
|/
* e1f2a3b Update configuration
* b0c1d2e Initial project setup
* a9b0c1d First commit

Why the DAG Matters

Every Git command manipulates the DAG. When you commit, you add a node. When you branch, you add a label. When you merge, you create a node with two parents. When you rebase, you copy nodes to a new location. When you understand the DAG, you can reason about any Git operation by thinking about how it changes the graph.

7. Experimentation Without Fear

The ultimate benefit of these concepts working together is freedom. When branches are free, commits are snapshots, and history is a graph, you can experiment without risking anything. This changes how you develop software.

The Safety Net

Every commit is an immutable snapshot. Once committed, your work is safe in the object database. Even if you delete a branch, the commits still exist (until garbage collection, which takes weeks by default). You can always recover. This means you can try risky refactors, explore wild ideas, and make mistakes, all without fear of losing your stable code.

# Create a branch for a risky experiment
$ git checkout -b experiment/new-algorithm

# Try something wild
$ echo "radical changes" > algorithm.py
$ git add . && git commit -m "Try new approach"

# It did not work? Just switch back. Nothing is lost.
$ git checkout main
# Your main branch is exactly as you left it.

# Delete the experiment branch if you want
$ git branch -D experiment/new-algorithm
# The commits still exist in the object database for ~30 days

# Or keep it and come back to it later
# Branches cost nothing

The Workflow This Enables

Professional Git workflows are built on this fearless experimentation. Feature branches, pull requests, code reviews, continuous integration, all of these practices depend on the ability to branch cheaply, commit often, and merge confidently. Without lightweight branches and snapshot-based commits, none of these workflows would be practical.

8. Version Control Concepts Flash Cards

10. FAQ

11. Common Mistakes & Gotchas