Introduction: What Git Actually Is

This chapter explains what git is under the hood, sets up your install, and walks you through creating your first repository.

What Git Actually Is

Git is two things pretending to be one.

Underneath, git is a small content-addressable database. It stores files by their hash. Identical content is stored once. That's the whole storage model.

On top, git is a set of commands that produce and navigate a graph of commits. Each commit is a snapshot of your project at a point in time, with a pointer to its parent commit (or parents, in a merge). Run a git command and you're either making a new node in that graph, moving to a different node, or asking the graph a question.

That's it. Once the graph clicks, the rest is learning which command does what to it.

Not What Git Is

People come to git with one of three bad mental models. It helps to name them so you can discard them.

"Git is a backup tool." It's not. Git tracks what you committed. If you didn't commit it, git doesn't have it. Uncommitted work can vanish when you switch branches or pull. Reach for real backups elsewhere.

"Git is like Dropbox." It's not. Dropbox syncs files continuously. Git records discrete snapshots with attached messages. The commits are the point, not the file contents.

"Git is patches and merges." Older VCSes (CVS, SVN) thought in patches. Git thinks in full snapshots internally; it just shows you patches. That distinction matters when you get to rebase and cherry-pick.

The Commit Graph

Every git repository is a graph. The nodes are commits. The edges are parent pointers. A typical graph looks like:

A --- B --- C --- D   (main)
               \
                E --- F   (feature/login)

A through D are commits on main. E and F are commits on a branch called feature/login, which started from C.

Branches, in git, are names for commits. main is a label on D. feature/login is a label on F. When you make a new commit on a branch, the label moves forward to the new commit.

HEAD is a special label meaning "where am I?". Usually HEAD points at a branch, and the branch points at a commit. When you switch branches, HEAD moves.

Keep this picture in your head. Every git command has a clear meaning once you know which node you're at and what you're doing to the graph.

Installing Git

On macOS:

brew install git

On Debian/Ubuntu:

sudo apt update
sudo apt install git

On Windows, download the installer from git-scm.com. Use "Git for Windows"; it includes Git Bash, a reasonable shell.

Confirm:

git --version
# git version 2.44.0

One-Time Configuration

Three settings you want immediately:

git config --global user.name  "Ada Lovelace"
git config --global user.email "ada@example.com"
git config --global init.defaultBranch main

The first two are baked into every commit you make. The third makes new repos start with a branch called main instead of the legacy master.

Two more worth setting:

git config --global pull.rebase true       # git pull rebases instead of merging
git config --global core.editor "vim"      # or "code --wait", "nano", etc.

pull.rebase true keeps history linear when you pull. You can always override per-pull.

Your First Repository

mkdir notes && cd notes
git init

Git prints something like:

Initialized empty Git repository in /home/ada/notes/.git/

You now have a .git/ directory. That's the repo. Everything git knows lives in there.

Make a file and commit it:

echo "# Notes" > README.md
git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

nothing added to commit but untracked files present

Git sees the file but isn't tracking it. Stage it, then commit:

git add README.md
git commit -m "first commit"

[main (root-commit) 3f1a22c] first commit
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Check the log:

git log

commit 3f1a22c1b... (HEAD -> main)
Author: Ada Lovelace <ada@example.com>
Date:   Sun Apr 19 10:15:02 2026 +0000

    first commit

One commit. One branch. HEAD pointing at main, main pointing at this commit. That's a complete, if small, git graph.

Three Life Stages

Every file in a git repository is in one of three places:

working tree  →  staging area (index)  →  committed history

• Working tree: the files on disk, as you see them in your editor.
• Staging area (also called the index): a snapshot you're building for the next commit.
• Committed history: the objects stored in .git/objects/, referenced by the graph.

git add moves changes from working tree to staging. git commit moves staged changes into history. git restore and its friends move things back.

Most git confusion comes from forgetting which stage a command operates on. Re-read the last paragraph when something surprises you.

A Peek at .git

You'll tour this properly in Chapter 9. For now, just notice it:

ls .git

HEAD        config      description  hooks/      info/
objects/    refs/

HEAD is a file. refs/heads/main is a file containing a commit hash. objects/ holds every commit, tree, and blob git has ever seen in this repo. Everything is text or binary data on disk. There's no magic.

Getting Help

Git has excellent built-in help.

git help commit      # opens the man page
git commit -h        # short usage summary
git help -a          # list every command

When a command confuses you, git help <command> is faster than Stack Overflow.

Next Steps

Continue to 02-basics.md for the daily commit loop.