# Your first commit: git init, status, add, commit

Course: Terminal Basics — https://zero2vibecode.com/learn/terminal-basics
Canonical URL: https://zero2vibecode.com/learn/terminal-basics/4-3-your-first-git-commit

Four commands take a folder from "just files" to a project with saved history: init, status, add, commit.

**Git** records the history of a folder. Every time you save a snapshot, it remembers exactly what every file looked like — and lets you go back.

This is the safety net under every AI coding session. When an agent rewrites twelve files and the result is worse, "go back to the last commit" is a one-line answer instead of an afternoon.

## git init — start tracking

```
git init
```

```
Initialized empty Git repository in /home/user/myproject/.git/
```

That created a hidden `.git` folder. Your files are untouched; git has simply started paying attention to them. Nothing has been uploaded anywhere — this is entirely local.

Git and GitHub are different things. Git is the program on your machine that records history. GitHub is a website that hosts copies of git repositories. You can use git for years without ever touching GitHub.

## git status — where do I stand

```
git status
```

```
On branch main
Untracked files:
	index.html
	style.css
```

Two files exist and git is not looking after either of them yet. **Untracked** means "I can see it, but I have never been told to record it".

`git status` is the `pwd` of git. Run it before you do anything and after you do anything. It is free, it changes nothing, and it always tells you the truth about where you are.

## git add — choose what goes in

```
git add .
```

The `.` means "everything in this folder". Run `git status` again:

```
On branch main
Changes to be committed:
	new file:   index.html
	new file:   style.css
```

The files have moved to **staged** — a waiting room for the next commit.

Why the extra step? Because you often change several unrelated things before you think to save. Staging lets you commit the bug fix by itself, then the styling change by itself, so the history reads as a series of decisions rather than a pile of Tuesdays.

```
git add index.html
```

stages just that one file.

## git commit — save the snapshot

```
git commit -m "first commit"
```

```
[main 0a1b2c3] first commit
 2 files changed
```

The `-m` flag carries the message. That message is what you will read in six months when you are trying to work out what happened, so make it say what changed and why:

- Bad: `update`, `fix`, `stuff`
- Good: `add the contact form`, `fix the crash on empty search`

Write the message as if finishing the sentence "this commit will…". "This commit will add the contact form." It keeps you in the habit of describing a change rather than naming a file.

Run `git status` one more time:

```
On branch main
nothing to commit, working tree clean
```

Everything on disk matches the last saved snapshot. That sentence is the calmest one in software.

## Try it

Git here is simulated. The workflow, the states and the messages match the real thing closely enough to build the habit, but no repository is created on your machine.

1. `git init` — start tracking.
2. `git status` — two untracked files.
3. `git add .` — stage them both.
4. `git status` — same files, now staged.
5. `git commit -m "first commit"` — save the snapshot.
6. `git status` — clean.

Run `git status` at every step, as listed. Watching the same files move from untracked to staged to committed is what makes the three states stick.