Your First Repository

Create the Project
git init: Start Tracking
git status: Your Best Friend
The Three Areas
git add: Stage a Change
git commit: Take the Snapshot
The Everyday Loop
.gitignore: Files Git Should Never Track
Try It Yourself

1. Create the Project

Make a folder for the website you'll build throughout this series, and open it in your editor:

cd ~
mkdir my-site
cd my-site
code .

In VS Code, create a file called index.html inside my-site with this content (change the name to yours):

<!DOCTYPE html>
<html>
  <head>
    <title>Dara's Site</title>
  </head>
  <body>
    <h1>Hi, I'm Dara</h1>
    <p>I'm learning Git.</p>
  </body>
</html>

Save it. If you like, double-click the file in your file manager to open it in a browser — it's a real web page.

Right now this is just an ordinary folder. Git doesn't know it exists.

2. git init: Start Tracking

To turn the folder into a Git repository, run this inside it:

git init

Initialized empty Git repository in /Users/dara/my-site/.git/

That one command created a hidden folder called .git inside my-site. Look for it:

ls -a

.          ..         .git       index.html

The .git folder is the repository. Every snapshot you ever take, every branch, and every setting for this project is stored inside it, as ordinary files. Your own files stay where they are, untouched.

Two warnings:

Don't edit or delete anything inside .git by hand. If you delete that folder, you delete the project's entire history — your current files survive, but every snapshot is gone.
Run git init once per project, in the project's top folder. Not in your home folder, and not inside a folder that's already a repository.

3. git status: Your Best Friend

git status tells you what Git sees right now. Run it constantly — before and after every other Git command, until it becomes a habit:

git status

On branch main

No commits yet

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

nothing added to commit but untracked files present (use "git add" to track)

Read it line by line:

On branch main — you're on the main line of work (branches come in chapter 6).
No commits yet — no snapshots exist so far.
Untracked files: index.html — Git can see this file, but it isn't tracking it. Git never tracks a file until you tell it to.

Notice that Git even tells you what to do next: use "git add". When you're unsure, git status almost always has a hint.

4. The Three Areas

Before you take a snapshot, you need one idea that makes the rest of Git make sense. Your project has three areas:

 Working directory      Staging area           Repository (.git)
 ─────────────────      ────────────           ─────────────────
 the files you see  →   changes packed for  →  the saved snapshots
 and edit               the next snapshot      (commits)
              git add               git commit

Working directory — your actual files, the ones you open and edit.
Staging area — a "packing box" for the next snapshot. You choose exactly which changes go in it.
Repository — the permanent history of snapshots, stored in .git.

Why the middle step? Because you often change several things at once, but they belong in separate snapshots. Say you fixed a typo and started a new section that isn't finished. With the staging area, you can snapshot just the typo fix now, and leave the half-done section for later. Each snapshot stays small and about one thing.

5. git add: Stage a Change

Put index.html into the staging area:

git add index.html
git status

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   index.html

"Changes to be committed" is the staging area. The file is packed and ready.

Some common ways to use git add:

git add index.html          # one file
git add index.html about.html   # several files
git add .                   # everything that changed in this folder

git add . is convenient, and you'll use it a lot — but always run git status first so you know exactly what "everything" includes.

6. git commit: Take the Snapshot

Now save the snapshot with a message describing it:

git commit -m "Add home page"

[main (root-commit) 3f2a1c9] Add home page
 1 file changed, 10 insertions(+)
 create mode 100644 index.html

That's your first commit. Git recorded the contents of the staging area, your name and email from chapter 2, the date and time, and the message. 3f2a1c9 is the start of the commit's unique ID — yours will be different. (Chapter 4 explains these IDs.)

Run git status again:

On branch main
nothing to commit, working tree clean

"Working tree clean" means your files match the latest snapshot exactly. Nothing is unsaved.

If you forget -m "..." and just type git commit, Git opens the editor you set in chapter 2 so you can write the message there. Type it on the first line, save, and close the tab.

7. The Everyday Loop

Almost all of your daily Git work is this loop:

edit files  →  git status  →  git add  →  git commit

Try one more lap. Add a line to index.html under the first paragraph:

    <p>I live in Phnom Penh.</p>

Save, then check:

git status

On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   index.html

no changes added to commit (use "git add" and/or "git commit -a")

Git noticed: the file is modified, but the change is only in the working directory — not staged yet. Stage and commit it:

git add index.html
git commit -m "Add where I live"

That's the whole loop. You now have two snapshots, and you can get back to either one.

When should you commit? Whenever you've finished one small, meaningful step that works — "Add contact link", "Fix broken image". Several small commits are much more useful than one giant commit at the end of the day.

8. .gitignore: Files Git Should Never Track

Some files should never go into a repository:

Secrets — passwords, API keys, .env files
Junk your OS creates — .DS_Store on macOS, Thumbs.db on Windows
Things you can rebuild — node_modules/, build output folders, log files

You list them in a special file called .gitignore in the top folder of the project. Create it now:

# macOS / Windows clutter
.DS_Store
Thumbs.db

# Secrets — never commit these
.env

# Dependencies and build output
node_modules/
dist/

Each line is a file name or pattern. A line ending in / means a whole folder; lines starting with # are comments. Git will now act as if those files don't exist — they won't show up in git status, and git add . will skip them.

The .gitignore file itself should be tracked, so everyone working on the project shares the same rules:

git add .gitignore
git commit -m "Add .gitignore"

Important: .gitignore only affects files Git isn't tracking yet. If you already committed a secret, adding it to .gitignore won't remove it from history. Treat that secret as leaked: change the password or create a new key.

9. Try It Yourself

Create my-site with the index.html above, and run git init.
Find the .git folder with ls -a, and turn on hidden files in your file manager to see it there too.
Make your first commits: "Add home page", then "Add where I live". Run git status before and after every command and read what it says.
Test the staging area. Change two lines in index.html — say, your heading and your city. Now create a new file notes.txt with anything in it. Run git status: one modified file, one untracked. Stage and commit only index.html, then run git status again. notes.txt is still untracked, waiting.
Ignore a file. Add notes.txt to .gitignore, then run git status. It disappears from the list. Commit the updated .gitignore.

You've saved several snapshots. Next, let's learn to read them.