Git & GitHub

Ce chapitre couvre les 3 commandes que vous utiliserez 90% du temps : git add pour sélectionner les fichiers, git commit pour sauvegarder, et git status pour voir où vous en êtes.

Le cycle de vie d'un fichier dans Git

Un fichier passe par 4 états :

1. Untracked (non suivi) — Git ne connaît pas ce fichier. C'est un nouveau fichier que vous n'avez jamais ajouté.
2. Staged (préparé) — Le fichier a été ajouté à la staging area avec git add. Il sera inclus dans le prochain commit.
3. Committed (enregistré) — Le fichier est sauvegardé dans l'historique Git via git commit.
4. Modified (modifié) — Le fichier a été modifié depuis le dernier commit. Git détecte les changements mais ne les sauvegarde pas tant que vous ne faites pas git add + git commit.

git status — savoir où vous en êtes

C'est la commande la plus utilisée. Elle montre :

• Les fichiers modifiés (en rouge) — pas encore ajoutés à la staging area
• Les fichiers staged (en vert) — prêts à être commités
• Les fichiers untracked — inconnus de Git

Prenez l'habitude de taper git status avant CHAQUE commit pour vérifier ce que vous allez sauvegarder.

git add — préparer les fichiers

• git add index.html — ajoute UN fichier spécifique
• git add css/ — ajoute tout un dossier
• git add . — ajoute TOUS les fichiers modifiés et nouveaux (le point signifie "tout")
• git add -A — similaire à git add . mais attrape aussi les fichiers supprimés

En pratique : git add . est le plus courant. Utilisez git add fichier quand vous voulez commiter seulement certains fichiers.

git commit — sauvegarder

git commit -m "votre message" crée un commit — un point de sauvegarde dans l'historique. Chaque commit a :

• Un hash unique (ex: a1b2c3d) — l'identifiant du commit
• Un message — la description de ce que vous avez changé
• Un auteur — votre nom et email (configurés au chapitre 0)
• Un timestamp — la date et l'heure

Le raccourci git commit -am "message" fait add + commit en une seule commande (seulement pour les fichiers DÉJÀ suivis — pas les nouveaux).

git log — voir l'historique

• git log — historique complet (détaillé, avec hash, auteur, date, message)
• git log --oneline — historique résumé (une ligne par commit)
• git log --oneline --graph — avec un graphique des branches (très utile)
• git log -5 — les 5 derniers commits

Écrire de bons messages de commit

Un bon message est court, au présent, et descriptif :

Les conventions (Conventional Commits) :

• feat: — nouvelle fonctionnalité : "feat: ajout du menu hamburger"
• fix: — correction de bug : "fix: correction du scroll sur mobile"
• style: — changement CSS sans impact fonctionnel : "style: refonte du héro"
• docs: — documentation : "docs: ajout du README"
• refactor: — restructuration sans changement fonctionnel : "refactor: extraction des fonctions utilitaires"
• chore: — maintenance : "chore: mise à jour des dépendances"

Mauvais messages : "update", "fix bug", "changements", "asdfgh", "wip". Ces messages ne disent rien sur ce qui a changé — dans 3 mois, ils sont inutiles.

> Règle d'or : Commitez souvent et petit. Un commit = UNE modification logique. Ne commitez pas une journée entière de travail en un seul commit géant. 5 petits commits sont infiniment plus utiles qu'un gros.