Local Repository and Commits

To understand commits, you first need to picture the three zones through which Git moves your files.

Analogy: packing a parcel. The working directory is your messy desk; the staging area is the box where you put what you want to send; the commit is the moment you seal the box and archive it.

To turn an ordinary folder into a Git repository:

# Go into the project folder
cd mon-projet

# Initialize the repository
git init

This creates a hidden .git/ subdirectory that contains the entire history and configuration of the repository.

# Check the state of the freshly created repository
git status

Never delete the .git/ folder: it contains the entire history. Deleting it means losing versioning (but not your current files).

🔧 Mini-exercise — Write the command that turns the current folder into a Git repository, then the one that displays its status.

git init
git status

A file can be tracked or untracked by Git.

# Stage a specific file
git add fichier.txt

# Stage every change in the folder
git add .

# See the status (tracked / untracked / staged)
git status

git status is your best friend: use it before and after every git add to see exactly what Git is about to record.

🔧 Mini-exercise — You just modified index.html and style.css. Write the command that stages only index.html.

git add index.html

A commit is a snapshot of your project at a given moment, together with a message that explains the change.

# Stage then record
git add .
git commit -m "Add the home page"

Each commit has:

# See the commit history
git log
git log --oneline   # compact version

A good commit is atomic: it does one coherent thing. Avoid the catch-all “lots of stuff” commit — prefer several small, clear commits.

🔧 Mini-exercise — Stage all your changes and create a commit whose message is “Add the contact page”.

git add .
git commit -m "Add the contact page"

The commit message tells the story of the project. A good message saves hours for the whole team (and for yourself in 6 months).

Basic rules

• Write in the present imperative: “Add…”, “Fix…”, “Remove…”.
• One short summary line (≤ 50 characters), then a detailed body if needed.
• Explain the why, not only the what.

Comparison

Common convention (Conventional Commits)

feat: add token authentication
fix: fix result pagination
docs: complete the installation README

Mnemonic: a good message should complete the sentence “If I apply this commit, it will…”. Example: “…add the home page”.

Some files must never be versioned: temporary files, bulky dependencies, secrets, compiled files. The .gitignore file tells Git to ignore them.

# Example contents of a .gitignore file
target/
node_modules/
*.log
.env
.DS_Store

Golden security rule: never commit passwords, API keys, or secrets. Once they are in the Git history, a secret stays there — even if deleted later. Put .env in .gitignore from the start.

🔧 Mini-exercise — Write the line to add to a .gitignore to stop Git from versioning the secrets file .env.

.env

Question 1: Which command turns an ordinary folder into a Git repository?

a) git start

b) git init

c) git new

d) git create

Question 2: What is the correct order of the three Git zones?

a) Repository → staging → working directory

b) Working directory → staging → local repository

c) Staging → repository → working directory

d) Working directory → repository → staging

Question 3: What is git add for?

a) Creating a commit

b) Preparing changes in the staging area

c) Deleting a file

d) Sending the code to GitHub

Question 4: Which one is a good commit message?

a) truc

b) wip

c) Fix the startup crash when the config is missing

d) .

Question 5: Why use a .gitignore?

a) To speed up the computer

b) To stop Git from versioning certain files (temporary files, secrets, dependencies)

c) To delete the history

d) To ignore commits

Instructions

Create a local repository, add a file, ignore a secret file, and make two clean commits.

Correction — Expected command sequence

# 1. Create and enter the folder
mkdir mon-premier-depot
cd mon-premier-depot

# 2. Initialize the repository
git init

# 3. Create a content file and a .gitignore
echo "# Mon projet" > README.md
echo ".env" > .gitignore
echo "SECRET=123" > .env        # this file must be ignored

# 4. Check the status (.env must NOT appear)
git status

# 5. First commit
git add README.md .gitignore
git commit -m "Initialize the project with README and gitignore"

# 6. Modify then second commit
echo "Description du projet" >> README.md
git add README.md
git commit -m "Complete the description in the README"

# 7. Consult the history
git log --oneline

Expected result:

b2c3d4e Complete the description in the README
a1b2c3d Initialize the project with README and gitignore

Check that .env never appears in git status: that is the proof your .gitignore works and your secret is protected.

Key takeaways

1. Three zones: working directory → staging (git add) → local repository (git commit).
2. git init creates the repository (.git/ folder).
3. A commit is a snapshot + a message, linked to the parent commit.
4. Good messages: imperative, clear, atomic, explaining the why.
5. .gitignore protects secrets and excludes useless files.

What's next

Lesson 07 — Branches and history: work on several versions in parallel without breaking the main version.