Les fondamentaux de Git

Les Trois Zones - Les fichiers passent du Working Directory au Staging puis au Repository

J'ai utilisé Git pendant un an avant de vraiment le comprendre.

Je mémorisais des commandes. git add ., git commit -m "fix", git push. Ça marchait. Jusqu'à ce que ça marche plus. Là je paniquais, je googlais l'erreur, et je copiais-collais des solutions que je comprenais pas.

Ça te parle ?

Cet article c'est ce que j'aurais aimé qu'on m'explique dès le début.

C'est quoi Git, vraiment ?

Git est un système de contrôle de version. Mais cette définition aide pas.

Voici une meilleure : Git est un système qui prend des photos de ton projet au fil du temps.

Chaque fois que tu commits, Git sauvegarde l'état entier de ton projet à ce moment. Pas juste les changements, tout. C'est comme sauvegarder une partie de jeu vidéo : tu peux toujours revenir à n'importe quelle sauvegarde précédente.

Ces snapshots sont liés entre eux, formant une timeline de ton projet.

HEAD c'est juste un pointeur vers où tu es maintenant. Généralement, il pointe vers ton dernier commit.

<details> <summary>🔍 Aller plus loin : comment Git stocke vraiment les données</summary>

Git ne stocke pas les différences entre fichiers (comme SVN). Il stocke des snapshots complets. Mais il est malin : si un fichier n'a pas changé, Git garde juste une référence vers la version précédente.

Chaque commit a un hash SHA-1 unique (ex: a1b2c3d). Ce hash est calculé à partir du contenu, donc deux commits identiques auront le même hash.

C'est pour ça que Git est si rapide pour naviguer dans l'historique : tout est indexé par ces hash.

</details>

Les trois zones

C'est le modèle mental qui a tout changé pour moi.

Git a trois zones :

Working directory : Les fichiers que tu vois et édites
Staging area (index) : Les fichiers que tu as marqués pour inclure dans ton prochain commit
Repository : L'historique de tous les commits

Quand tu édites un fichier, il change dans ton working directory. Git le remarque, mais ne fait rien encore.

Quand tu lances git add, tu déplaces ces changements vers la staging area. Tu dis "je veux ces changements dans mon prochain commit."

Quand tu lances git commit, Git prend tout ce qui est dans la staging area et crée un snapshot.

Tes premières commandes

git init

Crée un nouveau dépôt Git dans le dossier courant.

mkdir my-project
cd my-project
git init

Ça crée un dossier caché .git. C'est là que Git stocke tout.

[!WARNING] Ne touche jamais au dossier .git manuellement. Si tu le supprimes, tu perds tout l'historique.

git status

Te montre ce qui se passe. Utilise-le constamment.

git status

Il te dit :

Quels fichiers ont changé
Quels changements sont staged
Sur quelle branche tu es

C'est ton meilleur ami. Dans le doute, git status.

[!TIP] Prends l'habitude de lancer git status avant et après chaque commande. Tu sauras toujours où tu en es.

git add

Déplace les changements du working directory vers la staging area.

# Ajouter un fichier spécifique
git add index.html

# Ajouter tous les fichiers du dossier courant
git add .

# Ajouter tous les changements (y compris les suppressions)
git add -A

J'utilise git add . la plupart du temps. Mais parfois tu veux commit seulement certains fichiers, c'est là que tu les ajoutes individuellement.

git commit

Crée un snapshot à partir de la staging area.

git commit -m "Add login page"

Le flag -m te permet d'écrire un message en ligne. Sans lui, Git ouvre ton éditeur.

Un bon message de commit :

Commence par un verbe (Add, Fix, Update, Remove)
Est court (50 caractères ou moins)
Explique quoi, pas comment

# ❌ Mauvais
git commit -m "changes"
git commit -m "fixed stuff"
git commit -m "WIP"

# ✅ Bon
git commit -m "Add user authentication"
git commit -m "Fix login redirect loop"
git commit -m "Remove unused dependencies"

git log

Affiche l'historique des commits.

git log

Ça montre chaque commit avec son hash, auteur, date et message.

Pour une vue plus propre :

git log --oneline

Ça affiche un commit par ligne. Beaucoup plus facile à scanner.

git diff

Montre ce qui a changé.

# Changements dans le working directory (pas staged)
git diff

# Changements dans la staging area (seront dans le prochain commit)
git diff --staged

Le fichier .gitignore

Certains fichiers ne devraient pas être suivis : dépendances, build outputs, secrets.

Crée un fichier .gitignore à la racine de ton projet :

# Dépendances
node_modules/

# Build output
dist/
build/

# Variables d'environnement (secrets !)
.env
.env.local

# Fichiers OS
.DS_Store
Thumbs.db

# IDE
.idea/
.vscode/

Git ignorera tout fichier correspondant à ces patterns.

[!NOTE] Si tu as déjà commit un fichier, l'ajouter à .gitignore ne le supprimera pas. Tu dois d'abord le retirer du suivi :

git rm --cached .env
git commit -m "Remove .env from tracking"

Les dépôts distants

Jusqu'ici, tout est local. Pour partager ton code, tu as besoin d'un remote.

git remote

Lie ton dépôt local à un remote (généralement GitHub).

git remote add origin https://github.com/username/my-project.git

origin c'est juste un nom. C'est la convention. Tu pourrais l'appeler github ou banane. Mais reste sur origin.

git push

Envoie tes commits vers le remote.

git push origin main

Avant ton premier push, vérifie :

Tu as un remote configuré (git remote -v)
Tu es sur la bonne branche (git branch)
Tes changements sont commités (git status)

La première fois, tu auras peut-être besoin de :

git push -u origin main

Le -u définit l'upstream, donc la prochaine fois tu peux juste faire git push.

git pull

Récupère les commits depuis le remote.

git pull origin main

Ça fetch les changements et les merge dans ta branche locale.

git clone

Télécharge un dépôt distant.

git clone https://github.com/username/my-project.git

Ça crée un dossier avec le projet et tout son historique.

Erreurs courantes et comment les corriger

"J'ai commit sur la mauvaise branche"

# Annuler le dernier commit, garder les changements
git reset --soft HEAD~1

# Changer vers la bonne branche
git checkout correct-branch

# Commit à nouveau
git commit -m "Your message"

"Je dois changer mon dernier message de commit"

git commit --amend -m "Nouveau message"

Fais ça seulement si tu n'as pas encore push.

"J'ai ajouté un fichier que je n'aurais pas dû"

# Retirer du staging, garder le fichier
git reset HEAD filename

# Ou retirer complètement du suivi
git rm --cached filename

"Je veux annuler tous mes changements locaux"

# Annuler tous les changements dans le working directory
git checkout -- .

# Ou avec les versions récentes de Git
git restore .

[!WARNING] C'est destructif. Ces changements sont perdus définitivement. Assure-toi de vraiment vouloir les supprimer.

La cheat sheet

Commande	Ce qu'elle fait
`git init`	Créer un nouveau dépôt
`git status`	Voir ce qui se passe
`git add .`	Stage tous les changements
`git commit -m "msg"`	Créer un snapshot
`git log --oneline`	Voir l'historique des commits
`git diff`	Voir les changements non staged
`git push`	Envoyer vers le remote
`git pull`	Récupérer depuis le remote
`git clone url`	Télécharger un dépôt

Ce qu'il faut retenir

"Commit early, commit often." -- Mantra Git

Git c'est pas de la magie. C'est un système pour prendre des snapshots et naviguer entre eux.

Une fois que tu comprends les trois zones (working directory → staging → repository), tout le reste a du sens.

Prochain article, on parlera des branches, la fonctionnalité qui rend Git vraiment puissant.

C'est la partie 1 de ma série "Git & GitHub en 10 articles".

Des questions ? Contacte-moi sur LinkedIn ou découvre plus sur mon blog.