Module 03 — Your First Repository

Goal: Create a repo, understand the “three areas,” and confidently use add, commit, status, log, and diff — the commands you’ll use every single day.

3.1 Creating a repository

Make a folder, go into it, and turn it into a Git repo:

mkdir my-first-repo
cd my-first-repo
git init
# Initialized empty Git repository in .../my-first-repo/.git/

That git init did exactly one thing: it created a hidden .git folder. That folder is the entire repository database. Delete it and your project becomes a plain folder again (losing all history). We dissect that folder completely in Module 04. For now, peek at it:

ls -a        # the -a shows hidden files
# .  ..  .git

3.2 The three areas (the most important diagram in Git)

Git moves your work through three places. Understanding them removes 90% of beginner confusion.

   Working Directory          Staging Area              Repository
   (your real files)          (the "index")             (.git, committed history)
        │                          │                          │
        │   git add <file>         │                          │
        ├─────────────────────────►│                          │
        │                          │      git commit          │
        │                          ├─────────────────────────►│
        │                          │                          │

Working Directory: the actual files you see and edit in your folder.
Staging Area (a.k.a. the Index): a “loading dock” where you gather exactly the changes you want in your next snapshot. This is Git’s superpower — you choose precisely what goes into each commit, not just “everything that changed.”
Repository: the permanent history stored in .git. Once committed, a snapshot is safe.

The flow is always: edit → git add (stage) → git commit (save snapshot).

Why have a staging area at all? Because real work is messy. You might fix a bug and a typo at once, but want them in separate, clean commits. Staging lets you commit the bug fix alone, then the typo separately. It’s the difference between a tidy history and a junk drawer.

3.3 Making your first commit

Create a file, then walk it through the three areas:

echo "# My First Project" > README.md

git status
# Shows README.md as "Untracked" — Git sees it but isn't tracking it yet

Stage it (move to the staging area):

git add README.md
git status
# Now under "Changes to be staged" / "to be committed"

Commit it (save the snapshot):

git commit -m "Add project README"
# [main (root-commit) a1b2c3d] Add project README
#  1 file changed, 1 insertion(+)

That a1b2c3d is the short form of your commit’s hash (Module 01). You just made the first frame of your film reel.

Good commit messages are short, present-tense summaries of what the change does: “Add login validation,” not “stuff” or “fixed it.” A common convention: a 50-character summary line, optionally followed by a blank line and a longer explanation.

3.4 The everyday loop

From now on your daily rhythm is:

# 1. Edit some files in your editor...

# 2. See what changed
git status

# 3. Review the exact lines that changed
git diff

# 4. Stage what you want
git add file1.js file2.css
# or stage everything that changed:
git add .

# 5. Commit
git commit -m "Describe the change"

Shortcut for tracked files

If a file is already tracked (committed at least once before), you can stage and commit in one step:

git commit -am "Quick fix"

The -a auto-stages all modified tracked files. Note: it does not include brand-new (untracked) files — those still need an explicit git add.

3.5 Reading history with `git log`

git log
# commit a1b2c3d... (HEAD -> main)
# Author: Your Name <you@example.com>
# Date:   ...
#
#     Add project README

Make it readable and compact:

git log --oneline
# a1b2c3d (HEAD -> main) Add project README

# A beautiful one-line graph of all branches:
git log --oneline --graph --all --decorate

That last command is worth memorizing — it draws your whole history as a tree and shows where every branch points.

3.6 Understanding `git diff`

git diff shows you unstaged changes (working directory vs. staging area):

git diff

To see what you’ve already staged (staging area vs. last commit):

git diff --staged      # also written --cached

Reading a diff: lines starting with - (often red) were removed; lines starting with + (often green) were added. The @@ -1,3 +1,4 @@ markers tell you which line numbers the chunk covers.

3.7 What is `HEAD`?

You’ll see the word HEAD constantly. It’s simply “where you are right now” — a pointer to the commit (usually via a branch) that your working directory currently reflects. When you commit, HEAD moves forward to the new commit. When you switch branches, HEAD moves to point at that branch. We’ll see in Module 04 that HEAD is literally a tiny file in .git.

3.8 Ignoring files you don’t want tracked

Some files should never be committed: secrets, logs, build output, dependency folders (node_modules). List them in a file named .gitignore at the repo root:

# .gitignore
node_modules/
*.log
.env
dist/
.DS_Store

Git will then pretend those files don’t exist for staging purposes. (More patterns and gotchas in Module 09.)

Try it yourself

git init a new folder.
Create two files. Stage and commit only one of them. Run git status to confirm the other is still pending.
Edit the committed file, run git diff, then stage and commit the change.
Run git log --oneline --graph --all and admire your two-commit history.
Add a .gitignore with *.log, create a test.log, and confirm git status ignores it.

Key takeaways

git init creates the .git folder, which is the repository.
Changes flow through three areas: working directory → staging area → repository.
The daily loop is edit → add → commit, with status, diff, and log to see what’s happening.
HEAD means “where you are now.” .gitignore keeps junk out of your history.

Next: Module 04 — Inside the .git Folder