Bases de Git : init, add, commit et log pas à pas

Vous venez d’écrire trois fichiers pour une petite application de gestion d’inventaire, puis vous avez « amélioré » un détail — et plus rien ne fonctionne. Sans historique, impossible de revenir à la version qui marchait : vous êtes condamné à reconstruire de mémoire. Git résout exactement ce problème. Il enregistre des photographies successives de votre projet, datées et commentées, que vous pouvez consulter et restaurer à volonté. À la fin de ce tutoriel, vous saurez transformer n’importe quel dossier en dépôt Git, enregistrer des versions propres avec commit, et lire votre historique avec log — les gestes que vous répéterez des milliers de fois dans votre carrière.

🎯 Ce que vous allez apprendre

• Installer Git et le configurer correctement (identité, branche par défaut, éditeur).
• Initialiser un dépôt et comprendre le rôle du dossier caché .git.
• Distinguer les trois zones de Git (répertoire de travail, index, dépôt) et le pointeur HEAD.
• Enregistrer des versions avec git add et git commit, et rédiger de bons messages.
• Ignorer les fichiers indésirables avec .gitignore.
• Lire et explorer l’historique avec git log, git show et git diff.

🛠️ Ce que vous allez construire

Le fil rouge est un dépôt nommé boutique-inventaire : une petite application web (les fichiers index.html, app.js, style.css et README.md). Vous allez le placer sous contrôle de version, puis enregistrer plusieurs commits qui racontent son évolution. À la fin, git log affichera une chronologie lisible de votre travail — votre première « machine à remonter le temps ».

Prérequis

• Un terminal (PowerShell, Terminal macOS, ou un shell Linux).
• Git installé (on le vérifie à l’étape 1).
• Un éditeur de texte (VS Code par exemple).
• Niveau débutant. Test express : si vous savez créer un dossier et y éditer un fichier texte, vous êtes prêt.
• ⏱️ Temps estimé : environ 40 minutes.

Étape 1 — Installer Git et déclarer votre identité

Avant tout, vérifions que Git est présent. Git est un logiciel en ligne de commande ; chaque commande commence par le mot git suivi d’un sous-commande. Git publie des versions mineures à un rythme soutenu ; n’importe quelle version récente conviendra pour ce tutoriel, l’essentiel étant de disposer de la 2.23 ou d’une version ultérieure, car c’est à partir de la 2.23 que sont apparues les commandes modernes git switch et git restore.

git --version

Vous devriez voir une ligne du type git version 2.54.0. Si le terminal répond « commande introuvable », installez Git depuis le site officiel (git-scm.com/downloads) puis rouvrez le terminal.

Git inscrit votre nom et votre adresse dans chaque commit : c’est la signature de l’auteur. On la configure une seule fois, globalement (pour tous vos dépôts), avec l’option --global.

git config --global user.name "Awa Ndiaye"
git config --global user.email "awa@example.com"

Profitons-en pour fixer deux réglages confortables : le nom de la branche initiale (main, désormais le standard de l’industrie) et l’éditeur utilisé pour les messages longs.

git config --global init.defaultBranch main
git config --global core.editor "code --wait"

L’option init.defaultBranch existe depuis Git 2.28 ; elle évite l’ancien nom master. Vérifiez l’ensemble de votre configuration avec la commande suivante, qui liste toutes les clés actives :

git config --list

✅ Point d’étape — git config --list doit afficher user.name, user.email et init.defaultbranch=main. Si l’adresse e-mail est fausse, relancez simplement la commande git config --global user.email : elle écrase l’ancienne valeur.

Étape 2 — Créer le dépôt et son premier commit (votre quick win)

Créons le projet, puis transformons-le en dépôt Git. La commande git init crée un sous-dossier caché .git : c’est lui qui contient toute la base de données de l’historique. Tant qu’il est là, votre dossier est « versionné » ; si vous le supprimez, vous perdez l’historique mais pas vos fichiers.

mkdir boutique-inventaire
cd boutique-inventaire
git init

Git répond Initialized empty Git repository in .../boutique-inventaire/.git/. Créons maintenant un premier fichier, puis demandons à Git l’état des lieux avec git status, la commande que vous taperez le plus souvent.

echo "# Boutique Inventaire" > README.md
git status

Git signale README.md dans la section Untracked files (« fichiers non suivis ») : il voit le fichier mais ne le surveille pas encore. Pour l’enregistrer, deux gestes en deux temps — d’abord le préparer avec add, ensuite le graver avec commit.

git add README.md
git commit -m "Initialise le projet avec un README"

Git confirme avec une ligne contenant un identifiant court (par exemple a1b2c3d) : c’est le début du SHA, l’empreinte unique du commit. Félicitations technique : votre projet a maintenant une histoire. C’était le geste fondateur ; tout le reste n’en est que la variation.

✅ Point d’étape — Lancez git status : il doit afficher nothing to commit, working tree clean. Cela signifie que le contenu enregistré correspond exactement à vos fichiers.

Le modèle mental : trois zones et un pointeur

Pour ne plus jamais être perdu, il faut visualiser les trois zones que tout fichier traverse. Cette image est la clé qui débloque toute la suite de votre apprentissage.

• Le répertoire de travail (working directory) : vos fichiers réels, ceux que vous éditez.
• L’index, aussi appelé zone de préparation (staging area) : une antichambre où vous rassemblez ce qui fera partie du prochain commit.
• Le dépôt (le dossier .git) : la base de données des commits déjà enregistrés.

La commande git add copie une version du fichier du répertoire de travail vers l’index. La commande git commit grave le contenu de l’index dans le dépôt sous forme d’un nouveau commit. Cette séparation est précieuse : elle vous laisse composer un commit cohérent même si vous avez modifié dix fichiers, en n’ajoutant que ceux qui forment une unité logique.

Un détail capital : un commit Git n’est pas une liste de différences, c’est une photographie complète (un instantané) de tous les fichiers suivis à un instant donné. Chaque commit pointe vers son ou ses parents, formant une chaîne. Enfin, HEAD est un pointeur spécial qui désigne « où vous êtes » — le plus souvent, le dernier commit de la branche courante.

Étape 3 — Voir ce qui a changé avec status et diff

Ajoutons du contenu au projet pour observer Git réagir. Modifions le README et créons le squelette de l’application.

echo "Application de gestion de stock." >> README.md
echo "console.log('Inventaire prêt');" > app.js
git status -s

L’option -s donne une vue compacte : M README.md (modifié, modified) et ?? app.js (non suivi). Pour voir précisément ce qui a changé dans les fichiers déjà suivis, on utilise git diff, qui compare le répertoire de travail à l’index.

git diff

Git affiche les lignes ajoutées préfixées d’un +. Important : git diff seul ne montre pas les fichiers non suivis ni ce qui est déjà dans l’index. Une fois un fichier ajouté à l’index, comparez l’index au dernier commit avec git diff --staged (synonyme : --cached).

echo "/* feuille de style */" > style.css
git add app.js style.css README.md
git diff --staged

Vous voyez maintenant l’intégralité de ce qui partira au prochain commit. Cette double lecture — git diff pour le non-préparé, git diff --staged pour le préparé — est le réflexe qui vous évitera de commiter une ligne de débogage oubliée.

Étape 4 — Ajouter finement et ignorer le superflu

La commande git add a plusieurs visages selon ce que l’on veut préparer. Connaître ces variantes vous donne un contrôle chirurgical sur vos commits.

git add app.js          # un fichier précis
git add .               # tout ce qui est nouveau ou modifié dans le dossier courant
git add -A              # toutes les modifications du dépôt, y compris les suppressions
git add -p              # mode interactif : valider section par section

Le mode -p (pour patch) est un trésor méconnu : Git vous présente chaque bloc de modifications et vous demande si vous voulez l’inclure. Vous pouvez ainsi séparer deux changements faits dans le même fichier en deux commits distincts — un pour la correction, un pour la nouvelle fonctionnalité.

Certains fichiers ne doivent jamais entrer dans l’historique : dépendances volumineuses, secrets, fichiers temporaires. On les déclare dans un fichier .gitignore à la racine. Git ignorera alors tout chemin qui correspond à ces motifs.

echo "node_modules/" > .gitignore
echo ".env" >> .gitignore
echo "*.log" >> .gitignore
git add .gitignore
git commit -m "Ajoute le squelette de l'app et ignore les fichiers temporaires"

Désormais, un dossier node_modules ou un fichier secrets.env n’apparaîtra plus dans git status. Attention : .gitignore n’agit que sur les fichiers non encore suivis. Un fichier déjà commité continue d’être suivi même si vous l’ajoutez ensuite au .gitignore — il faudra alors le retirer explicitement (voir l’étape suivante).

✅ Point d’étape — Après ce commit, git status doit être propre et git log --oneline doit afficher deux commits. Si .env apparaît encore comme non suivi, vérifiez l’orthographe exacte dans .gitignore.

Étape 5 — Explorer l’historique avec log et show

L’intérêt d’enregistrer des versions, c’est de pouvoir les relire. git log affiche l’historique du plus récent au plus ancien : auteur, date, message et SHA complet. Pour une vue dense et lisible, on combine plusieurs options.

git log --oneline --graph --decorate --all

Décortiquons : --oneline condense chaque commit sur une ligne, --graph dessine la structure des branches en ASCII, --decorate affiche les noms de branches et d’étiquettes, et --all inclut toutes les branches (utile dès que vous en aurez plusieurs). Cette commande est si pratique que beaucoup de développeurs en font un alias.

Pour examiner un commit précis — message complet et différences ligne à ligne — on utilise git show suivi d’un identifiant (ou de HEAD pour le dernier).

git show HEAD

Enfin, git log -p combine l’historique et le détail des modifications de chaque commit : idéal pour comprendre quand et pourquoi une ligne précise est apparue. Vous tenez là un outil d’enquête redoutable lorsqu’un bug s’est glissé « quelque part ces derniers jours ».

Étape 6 — Renommer, déplacer, supprimer proprement

Renommer ou supprimer un fichier suivi se fait avec les variantes Git des commandes système, pour que l’opération soit enregistrée correctement dans l’index. Supposons que l’on renomme app.js en inventaire.js.

git mv app.js inventaire.js
git rm style.css        # supprime le fichier ET l'enlève du suivi
git status

Git affiche le renommage et la suppression déjà préparés dans l’index. Si vous voulez seulement cesser de suivre un fichier tout en le gardant sur le disque (cas du fichier ajouté trop tôt avant un .gitignore), utilisez l’option --cached.

git rm --cached config.local.js

Une remarque importante avant de clore : si vous vous trompez dans votre dernier message de commit, git commit --amend permet de le corriger. Mais cette commande réécrit le dernier commit ; les techniques d’annulation et de réparation (amend, reset, revert, reflog) méritent un traitement complet, abordé dans le tutoriel dédié à l’annulation et à la réparation.

Étape 7 — Vérification de bout en bout

Validons que tout fonctionne. Enregistrez l’état actuel, puis relisez l’historique complet.

git add -A
git commit -m "Renomme le script principal et nettoie les fichiers inutiles"
git log --oneline

Vous devez voir trois commits, du plus récent au plus ancien, chacun avec un message clair. Vous venez de réaliser le cycle complet de Git : modifier, préparer, enregistrer, inspecter. C’est la boucle que vous répéterez sur chaque projet.

🐞 Pièges fréquents

Travailler avec une connexion limitée

Git est conçu pour fonctionner hors ligne : tout l’historique vit dans le dossier .git, sur votre machine. Vous pouvez créer des dizaines de commits sans la moindre connexion Internet ; la synchronisation avec un serveur distant (abordée dans le tutoriel sur le travail collaboratif) ne se fait qu’au moment de partager. Cette propriété est un atout majeur quand la bande passante est rare ou coûteuse : on accumule son travail localement, et l’on envoie tout d’un coup lorsqu’une connexion est disponible. Pour les très gros dépôts, sachez aussi que git clone --depth 1 ne télécharge que le dernier instantané (un « clone superficiel »), ce qui économise temps et données — une option que vous garderez en réserve.

✅ Récapitulatif

Vous savez désormais initialiser un dépôt, comprendre les trois zones (travail, index, dépôt) et le rôle de HEAD, préparer vos changements avec les variantes de git add, les enregistrer avec des messages clairs, ignorer le superflu et explorer l’historique avec log, show et diff. Ce socle — la boucle modifier → add → commit → log — sous-tend absolument tout le reste de Git. La suite logique consiste à faire diverger votre travail en parallèle grâce aux branches.

🧾 Aide-mémoire

💪 À vous de jouer

Ajoutez un fichier style.css avec une règle CSS, puis créez deux commits distincts à partir d’une seule séance de travail : un pour le style, un autre pour une correction dans README.md. Indice : le mode interactif vous y aidera.

echo "body { font-family: sans-serif; }" > style.css
echo "## Installation" >> README.md
git add style.css
git commit -m "Ajoute une feuille de style de base"
git add README.md
git commit -m "Documente l'installation dans le README"
git log --oneline

FAQ

Q : Quelle différence entre git add et git commit ?
R : add place une version du fichier dans l’index (l’antichambre du prochain commit) ; commit grave définitivement le contenu de l’index dans l’historique. L’un prépare, l’autre enregistre.

Q : Mes fichiers sont-ils envoyés sur Internet quand je commite ?
R : Non. Tout reste local dans le dossier .git. L’envoi vers un serveur distant est une opération séparée (git push), traitée dans le tutoriel sur le travail collaboratif.

Q : Que mettre dans un message de commit ?
R : Une ligne de sujet courte (idéalement 50 caractères) à l’impératif décrivant l’intention (« Corrige l’affichage du stock »), suivie au besoin d’un paragraphe expliquant le pourquoi.

Q : Puis-je supprimer le dossier .git ?
R : Oui, mais vous perdrez tout l’historique. Vos fichiers actuels resteront, le dépôt redeviendra un simple dossier.

Q : git add . ou git add -A ?
R : add . ajoute les nouveautés et modifications du dossier courant ; add -A couvre tout le dépôt, y compris les suppressions, où que vous soyez dans l’arborescence.

Ressources

• Documentation officielle Git : git-scm.com/docs
• Livre Pro Git (gratuit, en français) : git-scm.com/book/fr/v2
• Pour les grands débutants, une mise en bouche : Git et GitHub pour débutants

Dans la même série

• Branches Git et fusion : créer, basculer, merger
• Annuler et réparer dans Git : reset, revert, reflog, stash

🔝 Retour au guide complet : Maîtriser Git et GitHub.