Le problème que personne n’ose avouer

On va commencer par une scène que tu as forcément vécue.

Tu bosses sur un script de déploiement. Il tourne. Les tests passent. Ton infra est stable. Et puis tu fais une modif. Une seule. “Juste un petit truc.”

Sauf que maintenant, plus rien ne marche. Tu veux revenir en arrière. Mais tu as sauvegardé par-dessus. C’est foutu.

Ou pire — ton collègue a bossé sur le même fichier Terraform que toi pendant la nuit. Le lendemain matin, quelqu’un écrase le travail de l’autre. Tensions dans l’équipe, rollback en prod, post-mortem un vendredi soir.

On rigole, mais regarde si ça te rappelle quelque chose :

deploy_script.sh
deploy_script_v2.sh
deploy_script_v2_corrigé.sh
deploy_script_FINAL.sh
deploy_script_FINAL_VRAIMENT_FINAL.sh
deploy_script_FINAL_PROD_OK_TOUCHE_PLUS.sh

Ce “système de versioning artisanal”, tout le monde l’a fait. Et tout le monde sait que ça ne tient pas la route.

C’est exactement pour ça que Git existe.

Git, c’est quoi concrètement ?

Avant de plonger dans les commandes, posons les bases. Tu dois comprendre ce que Git fait avant de comprendre comment il le fait.

Une définition simple

Git est un système de gestion de versions distribué. En clair :

Il prend des instantanés (appelés commits) de tes fichiers à chaque étape
Il conserve tout l’historique — tu peux revenir à n’importe quel moment dans le temps
Il permet de travailler en parallèle sur différentes versions de ton projet (les branches)
Il fusionne le travail de plusieurs personnes proprement
Et tout ça localement, sans avoir besoin d’Internet

🧠 À retenir : Git n’est pas un outil cloud. C’est un programme qui tourne sur ta machine. GitHub, GitLab, Bitbucket — ce sont des plateformes web qui hébergent tes dépôts Git distants. Ne confonds jamais les deux.

L’analogie du carnet de voyage

Imagine que tu écris un livre. Chaque soir, tu photographies ton manuscrit. Si demain tu fais une bêtise, tu peux revenir à la photo d’hier. Ou de la semaine dernière. Ou d’il y a six mois.

Maintenant, imagine que tu écris ce livre avec trois co-auteurs. Chacun travaille sur un chapitre différent, chacun de son côté. À la fin, vous fusionnez le tout. Et si deux personnes ont touché au même paragraphe ? Git te prévient et te laisse choisir quelle version garder.

Cette analogie n’est pas parfaite, mais elle capture l’essentiel : Git est un Ctrl+Z infini, avec la collaboration en bonus.

Pourquoi le versioning est non-négociable en DevOps

Tu pourrais te dire : “Ok, c’est pratique pour les développeurs. Mais moi je fais du DevOps, de l’infra, du cloud — en quoi ça me concerne ?”

Réponse courte : en tout.

Le versioning, c’est la fondation de tout le reste

Dans une culture DevOps, tout est code :

Ton infrastructure ? C’est du Terraform, du Pulumi, du CloudFormation. Du code.
Ta CI/CD ? C’est un .gitlab-ci.yml ou un Jenkinsfile. Du code.
Ta config serveur ? C’est de l’Ansible, du Chef, du Puppet. Du code.
Tes dashboards de monitoring ? Grafana as Code. Du code.
Tes politiques de sécurité ? Open Policy Agent. Du code.

Et tout code a besoin d’être versionné. Sans versioning, pas d’Infrastructure as Code. Sans IaC, pas de DevOps. C’est aussi simple que ça.

🔥 Cas réel en entreprise : Une équipe SRE chez un hébergeur suisse gérait ses règles firewall à la main via une interface web. Un jour, un junior a supprimé une règle critique en pensant qu’elle était obsolète. Résultat : 4 heures de downtime, des clients furieux, un post-mortem douloureux. Depuis, toutes les règles sont dans un repo Git avec review obligatoire avant merge. Plus jamais de “oups j’ai cliqué au mauvais endroit.”

Ce que Git te permet de faire au quotidien

Concrètement, en tant que DevOps/SRE, Git te permet de :

Historiser chaque modification avec un message explicatif — tu sais qui a changé quoi, quand, et pourquoi
Revenir en arrière à n’importe quel état précédent — un rollback en une commande
Travailler en parallèle sur plusieurs branches — une feature, un fix, un experiment, chacun dans son coin
Collaborer sans écraser le travail des autres — merge et pull requests
Tracer chaque changement pour l’audit et la conformité — obligatoire dans beaucoup de secteurs (finance, santé, etc.)
Automatiser les déploiements via des pipelines CI/CD déclenchés par des commits

💡 Tip DevOps : En entreprise, le repo Git devient la source de vérité unique (Single Source of Truth). Si c’est pas dans le repo, ça n’existe pas. Cette discipline semble rigide au début, mais elle te sauvera la vie le jour où tu devras comprendre pourquoi un changement a été fait il y a 6 mois à 3h du matin.

Git vs les autres systèmes de versioning

Git n’est pas le seul système de gestion de versions qui ait existé. Mais c’est celui qui a gagné, et de loin. Pour comprendre pourquoi, un peu d’histoire.

Les systèmes centralisés (l’ancien monde)

Avant Git, on utilisait des systèmes centralisés comme SVN (Subversion) ou CVS. Le principe : un serveur central détient l’historique complet. Les développeurs “checkoutent” les fichiers, travaillent dessus, puis les “commitent” au serveur.

Le problème ? Si le serveur tombe, personne ne peut travailler. Pas de commit, pas d’historique, pas de branches. Tout le monde est bloqué. Et si le disque du serveur lâche sans backup… l’historique est perdu. Pour toujours.

Git : le système distribué

Git fonctionne différemment. Chaque développeur possède une copie complète du dépôt, y compris tout l’historique. Tu peux commiter, créer des branches, consulter les logs — le tout sans connexion réseau.

Le serveur distant (GitHub, GitLab…) n’est qu’un point de synchronisation. Si GitHub tombe pendant 2 heures, tu continues à bosser tranquillement.

Système	Type	Statut actuel
Git	Distribué	✅ Standard absolu de l’industrie
Mercurial (hg)	Distribué	Quasi disparu (Facebook l’utilisait, a migré)
SVN	Centralisé	Legacy — encore dans certaines grosses boîtes
CVS	Centralisé	☠️ Mort et enterré
Perforce	Centralisé	Niche (jeux vidéo, gros binaires)

🧠 À retenir : Git a été créé en 2005 par Linus Torvalds — oui, le créateur de Linux. Il l’a conçu pour gérer le développement du kernel Linux, un projet avec des milliers de contributeurs et des millions de lignes de code. Si Git peut gérer ça, il peut gérer ton projet.

GitHub, GitLab, Bitbucket — ne confonds pas l’outil et la plateforme

C’est une confusion très courante chez les débutants, et même parfois chez les moins débutants. Clarifions une bonne fois pour toutes.

Git = l’outil en ligne de commande, installé localement sur ta machine
GitHub = une plateforme web (propriété de Microsoft) qui héberge des repos Git et ajoute des fonctionnalités sociales et CI/CD
GitLab = une plateforme similaire, qui peut être auto-hébergée (très populaire en entreprise)
Bitbucket = la plateforme d’Atlassian (intégrée à Jira)

L’analogie la plus simple : Git, c’est le moteur. GitHub/GitLab, c’est la carrosserie avec le GPS, les sièges chauffants et le système audio.

Tu peux utiliser Git sans jamais toucher à GitHub. Tu peux avoir un repo Git purement local, ou synchronisé avec ton propre serveur via SSH. Les plateformes sont un confort, pas une nécessité.

💡 Tip DevOps : En entreprise, le choix entre GitHub et GitLab dépend souvent de la stratégie CI/CD. GitLab a un pipeline CI/CD intégré très puissant. GitHub Actions est plus récent mais s’est énormément amélioré. Les deux sont de très bons choix. Le plus important, c’est d’en choisir un et de s’y tenir.

Prérequis

Avant de commencer, vérifie que tu as :

Un terminal fonctionnel — si tu as suivi le chapitre Linux, tu es paré
Un éditeur de texte — Vim, Nano, VS Code, peu importe. Quelque chose pour éditer des fichiers
Aucune expérience en programmation — ce cours part de zéro

Git fonctionne sur Linux, macOS et Windows. Les commandes sont identiques partout — c’est l’un de ses grands avantages.

Ce que tu vas apprendre dans ce chapitre

🔄 Pourquoi le versioning est la fondation de toute pratique DevOps
⚙️ Comment installer et configurer Git proprement sur ta machine
🧠 Les concepts fondamentaux : working directory, staging area, repository
📸 Faire tes premiers commits — les “instantanés” de ton projet
🔍 Naviguer dans l’historique et comprendre ce qui a changé
🚫 Créer un .gitignore pour exclure les fichiers sensibles ou inutiles
↩️ Annuler des changements quand tu te trompes
✍️ Écrire des messages de commit propres et professionnels

🎯 Objectif : À la fin de ce chapitre, tu sauras initialiser un dépôt Git, comprendre les trois zones fondamentales, faire des commits propres, naviguer dans l’historique et annuler des changements.

⏱️ Durée estimée : 45 minutes | Niveau : Débutant

1. Installation de Git

Pourquoi c’est la première étape

Ça peut sembler évident, mais beaucoup de distributions Linux n’incluent pas Git par défaut, ou incluent une version ancienne. Et sur macOS, la version pré-installée (via Xcode Command Line Tools) est souvent en retard de plusieurs versions majeures.

On va installer la dernière version stable et vérifier que tout fonctionne.

Sur Debian / Ubuntu

La commande apt install git-all installe Git et tous ses compléments (documentation, outils d’email, interface graphique gitk). Si tu veux une installation minimale, git seul suffit, mais git-all ne coûte pas grand-chose en espace disque et t’évite des surprises plus tard.

sudo apt update
sudo apt install git-all

Sur RHEL / Fedora / CentOS

Sur les distributions Red Hat, on utilise dnf (ou yum sur les anciennes versions) :

sudo dnf install git

Sur macOS

Si tu utilises Homebrew (et tu devrais), c’est la méthode la plus propre. Homebrew te donnera toujours une version récente :

brew install git

⚠️ Attention : Sur macOS, si tu tapes git sans l’avoir installé, le système te proposera d’installer les Xcode Command Line Tools. Ça fonctionne, mais la version de Git sera souvent ancienne. Préfère Homebrew pour rester à jour.

Sur Windows

Télécharge l’installateur depuis git-scm.com. Il inclut Git Bash, un émulateur de terminal Unix qui te permettra d’utiliser les mêmes commandes que sur Linux/macOS.

Vérifier l’installation

Quelle que soit ta plateforme, cette commande te confirme que Git est bien installé et te donne la version :

git --version

Tu devrais obtenir quelque chose comme :

git version 2.43.0

💡 Tip DevOps : Dans un contexte d’automatisation, tu peux vérifier la version de Git dans tes scripts CI/CD pour t’assurer d’un comportement cohérent entre environnements. Les versions majeures de Git peuvent introduire des changements de comportement. Bonne pratique : épingler une version minimale dans ta documentation.

2. Configuration initiale — te présenter à Git

Pourquoi configurer avant de commencer

Chaque commit Git contient trois informations essentielles :

Quoi — les fichiers modifiés
Quand — la date et l’heure
Qui — le nom et l’email de l’auteur

Si tu ne configures pas ton identité, Git va soit refuser de commiter, soit utiliser des valeurs par défaut tirées de ton système (et ça donne des trucs moches comme root@localhost).

C’est aussi une question de traçabilité : en entreprise, on doit pouvoir savoir qui a fait quel changement. Un commit signé “Unknown” dans l’historique, c’est un red flag en audit.

Configurer ton identité

Ces deux commandes sont obligatoires. Sans elles, tu ne peux pas commiter :

git config --global user.name "Ton Nom"
git config --global user.email "ton@email.com"

Le flag --global signifie que cette configuration s’applique à tous tes repos sur cette machine. C’est ce que tu veux dans 99% des cas.

🔥 Cas réel en entreprise : Utilise ton email professionnel pour les repos pro, et ton email perso pour tes projets perso. Tu peux configurer un email différent par repo avec --local. Si tu contribues à l’open source avec ton email corporate, vérifie les politiques de ta boîte — certaines entreprises n’aiment pas ça.

Choisir ton éditeur par défaut

Quand Git a besoin que tu écrives un message (commit, merge, rebase interactif), il ouvre un éditeur de texte. Par défaut, c’est souvent Vim, ce qui peut être déroutant si tu n’y es pas habitué.

Tu peux changer l’éditeur selon tes préférences :

# Pour Vim (par défaut sur beaucoup de systèmes)
git config --global core.editor "vim"

# Pour Nano (plus simple pour les débutants)
git config --global core.editor "nano"

# Pour VS Code (attend que tu fermes l'onglet)
git config --global core.editor "code --wait"

⚠️ Attention : Si tu choisis VS Code, le --wait est crucial. Sans lui, Git pense que tu as terminé immédiatement et utilise un message vide — ce qui annule le commit. C’est un piège classique.

Configurer la branche par défaut

Historiquement, Git nommait la branche initiale master. Depuis quelques années, la convention a évolué vers main. Pour éviter toute confusion et suivre les standards actuels :

git config --global init.defaultBranch main

Gérer les fins de ligne (line endings)

C’est un détail qui peut te rendre fou si tu travailles dans une équipe mixte Linux/macOS/Windows. Les systèmes n’utilisent pas le même caractère de fin de ligne :

Linux/macOS : LF (Line Feed, \n)
Windows : CRLF (Carriage Return + Line Feed, \r\n)

Git peut convertir automatiquement :

# Sur macOS / Linux : convertit CRLF → LF à l'entrée, ne touche rien à la sortie
git config --global core.autocrlf input

# Sur Windows : convertit LF → CRLF à la sortie, CRLF → LF à l'entrée
git config --global core.autocrlf true

🧠 À retenir : Si tu travailles seul sur Linux, tu peux ignorer ce paramètre. Mais dès que tu collabores avec des gens sur Windows, configure-le. Sinon, tes diffs seront pollués par des changements de fins de ligne sur chaque fichier, et ça rend la code review impossible.

Activer la coloration syntaxique

Par défaut, Git affiche tout en texte brut dans le terminal. Active les couleurs pour rendre la lecture beaucoup plus agréable :

git config --global color.ui auto

Avec cette option, git status affichera les fichiers modifiés en rouge, les fichiers stagés en vert, les branches en couleur dans les logs… C’est un petit confort qui change tout.

Vérifier ta configuration

Pour afficher toute ta configuration Git actuelle et t’assurer que tout est correct :

git config --list

Tu peux aussi vérifier une valeur spécifique :

git config user.name
git config user.email

Les trois niveaux de configuration

Git a un système de configuration en couches, du plus général au plus spécifique :

Niveau	Flag	Fichier	Portée
System	`--system`	`/etc/gitconfig`	Tous les utilisateurs de la machine
Global	`--global`	`~/.gitconfig`	Ton compte utilisateur
Local	`--local`	`.git/config`	Le dépôt courant uniquement

Le local surcharge le global, qui surcharge le system. C’est un pattern d’héritage classique.

💡 Tip DevOps : Tu peux versionner un template de .gitconfig global dans un repo “dotfiles” et l’installer automatiquement sur chaque nouvelle machine avec un script. Ça fait partie de la philosophie “tout en code” — même ta config personnelle.

3. Les concepts fondamentaux — le modèle mental de Git

Avant de taper la moindre commande, tu dois comprendre comment Git pense. Si tu sautes cette section, tu vas mémoriser des commandes sans comprendre ce qu’elles font, et tu seras perdu dès que quelque chose ne se passera pas comme prévu.

Les trois zones de Git

C’est LE concept clé. Tout le fonctionnement de Git repose sur trois zones distinctes :

graph TB
  WD[Working Directory] -->|git add| SA[Staging Area]
  SA -->|git commit| LR[Local Repo]
  LR -->|git push| RR[Remote Repo]
  RR -->|git pull| WD
  style WD fill:#1a2332,stroke:#f59e0b,color:#f1f5f9
  style SA fill:#1a2332,stroke:#3b82f6,color:#f1f5f9
  style LR fill:#1a2332,stroke:#22c55e,color:#f1f5f9
  style RR fill:#1a2332,stroke:#a855f7,color:#f1f5f9

Décortiquons chaque zone :

1. Le Working Directory (répertoire de travail)

C’est ton dossier de projet tel que tu le vois dans ton explorateur de fichiers ou ton terminal. Les fichiers que tu édites, que tu crées, que tu supprimes — tout ça se passe dans le working directory.

Git observe ce dossier et détecte les changements par rapport au dernier commit. Mais il ne les enregistre pas automatiquement. C’est toi qui décides quoi sauvegarder.

Analogie : c’est ton bureau physique. Tu as des feuilles étalées dessus, certaines en cours de rédaction, d’autres finies. Le bureau, c’est le working directory.

2. La Staging Area (zone de préparation)

C’est une zone intermédiaire, aussi appelée index. Quand tu fais git add, tu déplaces un fichier du working directory vers la staging area. Tu dis à Git : “Ce fichier-là, je veux l’inclure dans mon prochain commit.”

Pourquoi cette étape intermédiaire ? Parce qu’elle te donne un contrôle fin sur ce que tu commites. Tu as peut-être modifié 10 fichiers, mais tu ne veux en commiter que 3 pour l’instant. La staging area te permet de faire ça.

Analogie : c’est la pile “à envoyer” sur ton bureau. Tu sélectionnes les feuilles finies et tu les poses dans cette pile. Quand tu es prêt, tu les mets dans l’enveloppe (le commit).

3. Le Repository (dépôt)

C’est l’historique complet de ton projet, stocké dans le dossier caché .git/ à la racine de ton projet. Chaque commit est un instantané de l’état de tes fichiers à un moment donné.

Le repository est local — il vit sur ta machine. Tu peux ensuite le synchroniser avec un remote (GitHub, GitLab…) via git push et git pull, mais ce n’est pas obligatoire.

Analogie : c’est ton classeur d’archives. Chaque enveloppe scellée (commit) y est rangée chronologiquement. Tu peux rouvrir n’importe laquelle pour voir l’état de ton travail à ce moment-là.

🧠 À retenir : Ce workflow en deux étapes (add puis commit) est ce qui rend Git puissant. Beaucoup de débutants ne comprennent pas pourquoi il faut “ajouter” avant de “commiter”. La réponse : parce que ça te permet de construire des commits propres et cohérents, même quand tu as touché à plein de fichiers différents.

Les quatre états d’un fichier

Chaque fichier dans un repo Git peut être dans l’un de ces quatre états :

Untracked → Staged → Committed → Modified → Staged → Committed → ...

État	Ce que ça signifie	Analogie
Untracked	Git ne connaît pas ce fichier — il vient d’être créé	Un nouveau post-it sur ton bureau
Staged	Le fichier est marqué pour le prochain commit	Le post-it est dans la pile “à envoyer”
Committed	Le fichier est enregistré dans l’historique	Le post-it est archivé dans le classeur
Modified	Le fichier a été changé depuis le dernier commit	Tu as re-gribouillé sur un post-it déjà archivé

💡 Tip DevOps : Utilise git status tout le temps. C’est ta boussole. Cette commande te dit exactement dans quel état se trouve chaque fichier. Prends l’habitude de la lancer avant chaque add et chaque commit. C’est le meilleur moyen d’éviter les surprises.

4. Ton premier dépôt Git — la pratique

Maintenant que tu as le modèle mental, passons à la pratique. On va créer un dépôt Git from scratch et explorer chaque commande.

Initialiser un dépôt avec `git init`

La commande git init crée un nouveau dépôt Git dans le dossier courant. Concrètement, elle crée un dossier caché .git/ qui contient toute la machinerie interne de Git (l’historique, la config locale, les références de branches…).

C’est la toute première commande que tu lances quand tu démarres un nouveau projet :

mkdir mon-projet
cd mon-projet
git init

Tu devrais voir :

Initialized empty Git repository in /home/user/mon-projet/.git/

Vérifions que le dossier .git/ a bien été créé :

ls -la

Tu verras un dossier .git/ — c’est là que Git stocke tout. Ne touche jamais à ce dossier manuellement, sauf si tu sais exactement ce que tu fais.

⚠️ Attention : git init dans un dossier qui contient déjà un .git/ ne détruit rien — il réinitialise certaines configurations, mais l’historique est préservé. Pas de panique si tu le lances par erreur dans un repo existant.

Créer un fichier et observer `git status`

Avant de faire quoi que ce soit, prenons l’habitude de vérifier l’état du repo. La commande git status te donne une vue d’ensemble de ce qui se passe :

git status

Sur un repo vide, tu verras :

On branch main
No commits yet
nothing to commit (create/copy files and use "git add" to track)

Parfait. Maintenant, créons un fichier :

echo "# Mon Projet DevOps" > README.md

Et relançons git status :

git status

On branch main
No commits yet
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

nothing added to commit but untracked files present (use "git add" to track)

Git te dit que README.md est untracked — il voit le fichier, mais ne le suit pas encore. Git te suggère même la commande à utiliser (git add). C’est un outil très bavard et très pédagogue.

Stager un fichier avec `git add`

La commande git add déplace un fichier du working directory vers la staging area. Tu dis à Git : “Ce fichier, je le veux dans mon prochain commit.”

git add README.md

Vérifions :

git status

On branch main
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md

Le fichier est maintenant en vert (si tu as activé les couleurs) et dans la section “Changes to be committed”. Il est stagé, prêt à être commité.

💡 Tip DevOps : Tu peux stager tous les fichiers modifiés d’un coup avec git add . (le point signifie “tout dans le dossier courant”). C’est pratique, mais dangereux — tu risques d’inclure des fichiers que tu ne voulais pas (logs, secrets, fichiers temporaires). Préfère git add <fichier> pour les commits importants, et utilise toujours git status avant de commiter.

Faire ton premier commit avec `git commit`

Un commit, c’est un instantané de ta staging area à un instant T. Chaque commit a un identifiant unique (un hash SHA-1), un auteur, une date, et un message qui décrit le changement.

La commande git commit prend tout ce qui est dans la staging area et l’enregistre dans l’historique :

git commit -m "Initial commit: ajout du README"

Le flag -m te permet de passer le message directement en ligne de commande. Sans -m, Git ouvrirait ton éditeur de texte pour que tu écrives le message.

Tu devrais voir quelque chose comme :

[main (root-commit) a1b2c3d] Initial commit: ajout du README
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Décortiquons cette sortie :

main — la branche courante
(root-commit) — c’est le tout premier commit du repo
a1b2c3d — les 7 premiers caractères du hash SHA-1 (l’identifiant unique)
1 file changed, 1 insertion(+) — le résumé des changements

🧠 À retenir : Un bon commit est atomique — il contient un seul changement logique. Ne mélange pas un bugfix et une nouvelle feature dans le même commit. Si tu dois annuler le bugfix plus tard, tu serais obligé d’annuler la feature aussi.

Voir l’historique avec `git log`

La commande git log affiche l’historique des commits, du plus récent au plus ancien :

git log

commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0 (HEAD -> main)
Author: Ton Nom <ton@email.com>
Date:   Thu Mar 20 10:30:00 2026 +0100

    Initial commit: ajout du README

Pour un affichage plus compact, une ligne par commit :

git log --oneline

a1b2c3d Initial commit: ajout du README

Et pour un affichage graphique avec les branches (très utile quand on en aura plusieurs) :

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

💡 Tip DevOps : Cette dernière commande est tellement utile qu’on va en faire un alias plus tard. Retiens-la — c’est ta vue “hélicoptère” sur l’historique du projet.

5. Le workflow quotidien — modifier, stager, commiter

Maintenant que tu as un premier commit, simulons un workflow réaliste.

Modifier un fichier existant

Ajoutons du contenu à notre README :

echo "" >> README.md
echo "## Description" >> README.md
echo "Projet de formation Git pour DevOps." >> README.md

Vérifions ce que Git détecte :

git status

On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
        modified:   README.md

Le fichier est modified — Git sait qu’il a changé, mais il n’est pas encore stagé.

Voir ce qui a changé avec `git diff`

Avant de stager, c’est une bonne habitude de vérifier exactement ce qui a changé. La commande git diff te montre les différences entre le working directory et la staging area :

git diff

diff --git a/README.md b/README.md
index 1234567..abcdefg 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,4 @@
 # Mon Projet DevOps
+
+## Description
+Projet de formation Git pour DevOps.

Les lignes en + vert sont les ajouts. Les lignes en - rouge seraient les suppressions. C’est exactement ce qu’on a ajouté.

⚠️ Attention : git diff sans argument montre les changements non stagés uniquement. Si tu as déjà fait git add, utilise git diff --staged (ou git diff --cached) pour voir ce qui est dans la staging area et qui sera inclus dans le prochain commit.

Stager et commiter

git add README.md
git commit -m "docs: ajout de la description du projet"

Créer un nouveau fichier

Ajoutons un script simple à notre projet :

cat > deploy.sh << 'EOF'
#!/bin/bash
echo "Déploiement en cours..."
echo "Environnement: $1"
EOF
chmod +x deploy.sh

git status

Le fichier est untracked. Stager et commiter :

git add deploy.sh
git commit -m "feat: ajout du script de déploiement initial"

Vérifions l’historique :

git log --oneline

c3d4e5f feat: ajout du script de déploiement initial
b2c3d4e docs: ajout de la description du projet
a1b2c3d Initial commit: ajout du README

Trois commits propres, chacun avec un message clair. C’est exactement comme ça qu’un historique Git doit se lire.

🔥 Cas réel en entreprise : Dans les équipes DevOps matures, l’historique Git est traité comme de la documentation. Quand un incident survient à 3h du matin, le premier réflexe de l’ingénieur d’astreinte est de regarder git log pour comprendre quels changements ont été déployés récemment. Des messages de commit clairs, c’est du temps gagné en situation de crise.

6. Le `.gitignore` — protéger ton repo

Pourquoi certains fichiers n’ont rien à faire dans Git

Tous les fichiers de ton projet ne doivent pas être versionnés. Voici les catégories classiques à exclure :

Secrets et credentials : .env, clés SSH, tokens API, mots de passe
Fichiers générés : node_modules/, __pycache__/, *.pyc, binaires compilés
Fichiers temporaires : logs, caches, fichiers .swp de Vim
Fichiers spécifiques à l’OS : .DS_Store (macOS), Thumbs.db (Windows)
Fichiers spécifiques à l’IDE : .idea/ (JetBrains), .vscode/ (parfois)

Le fichier .gitignore à la racine de ton repo indique à Git quels fichiers ignorer.

Créer un `.gitignore`

cat > .gitignore << 'EOF'
# Secrets et variables d'environnement
.env
.env.*
*.pem
*.key

# Dépendances
node_modules/
vendor/
.venv/

# Fichiers générés
*.pyc
__pycache__/
*.o
*.class
dist/
build/

# Logs
*.log
logs/

# OS
.DS_Store
Thumbs.db

# IDE
.idea/
*.swp
*.swo
*~
EOF

git add .gitignore
git commit -m "chore: ajout du .gitignore"

🧠 À retenir : Le .gitignore ne fonctionne que pour les fichiers non encore suivis par Git. Si tu as déjà commité un fichier .env et que tu l’ajoutes ensuite au .gitignore, Git continuera à le suivre. Pour le “détracker”, il faut utiliser git rm --cached .env.

🔥 Cas réel en entreprise : Des centaines de fuites de données majeures ont été causées par des secrets commités accidentellement dans des repos Git publics. Des bots scannent GitHub en permanence à la recherche de clés AWS, tokens API, mots de passe de base de données. Toujours avoir un .gitignore qui exclut les secrets. Et si tu commites un secret par erreur, considère-le comme compromis — le supprimer d’un commit ultérieur ne l’efface pas de l’historique.

💡 Tip DevOps : Le site gitignore.io (ou toptal.com/developers/gitignore) génère des .gitignore adaptés à ton stack. Tape “Python, Linux, VSCode” et il te génère un fichier complet. Très pratique pour démarrer un projet.

7. Annuler des changements — le filet de sécurité

C’est là que Git révèle toute sa puissance. Tu vas te tromper — c’est normal, c’est humain. L’important, c’est de savoir comment revenir en arrière.

Annuler des modifications non stagées

Tu as modifié un fichier mais tu veux revenir à la version du dernier commit (annuler tes modifications dans le working directory) :

# Restaurer un fichier spécifique
git checkout -- deploy.sh

# Syntaxe moderne (Git 2.23+), plus explicite
git restore deploy.sh

⚠️ Attention : Cette commande est irréversible. Les modifications non stagées et non commitées sont perdues pour toujours. Git ne peut pas les récupérer parce qu’elles n’ont jamais été enregistrées. Assure-toi de vraiment vouloir les jeter avant de lancer cette commande.

Déstaguer un fichier (le retirer de la staging area)

Tu as fait git add sur un fichier mais tu ne veux finalement pas l’inclure dans le prochain commit :

# Retirer de la staging area (le fichier reste modifié dans le working directory)
git reset HEAD deploy.sh

# Syntaxe moderne (Git 2.23+)
git restore --staged deploy.sh

Le fichier repasse de “staged” à “modified”. Tes modifications sont préservées — elles sont juste retirées de la staging area.

Modifier le dernier commit

Tu as commité mais tu as oublié un fichier, ou tu veux corriger le message :

# Ajouter un fichier oublié au dernier commit
git add fichier_oublie.txt
git commit --amend

# Juste corriger le message du dernier commit
git commit --amend -m "fix: message corrigé"

⚠️ Attention : --amend réécrit l’historique. Si tu as déjà pushé le commit sur un remote, tu devras faire un git push --force, ce qui peut poser des problèmes si d’autres personnes travaillent sur la même branche. En règle générale : --amend uniquement sur des commits pas encore pushés.

Revenir à un commit précédent (consultation)

Tu veux voir l’état du projet à un moment donné, sans modifier l’historique :

# Se déplacer temporairement sur un ancien commit
git checkout a1b2c3d

# Revenir à la branche principale
git checkout main

C’est ce qu’on appelle le mode “detached HEAD” — tu es sur un commit spécifique, pas sur une branche. Tu peux regarder, mais si tu veux garder des changements, il faudra créer une branche (on verra ça dans un prochain chapitre).

🧠 À retenir : Git est conçu pour que tu puisses toujours revenir en arrière. La seule exception : les modifications jamais commitées ni stagées. Tout ce qui a été commité au moins une fois est récupérable, même si tu le supprimes. C’est le pouvoir du versioning.

8. Écrire des messages de commit professionnels

Pourquoi c’est important

Un message de commit, c’est une lettre à ton futur toi. Dans six mois, quand tu chercheras pourquoi un changement a été fait, c’est le message de commit qui te répondra. Un mauvais message te laissera dans le noir.

Regarde la différence :

# ❌ Mauvais
fix
update
modifs
wip
asdf

# ✅ Bon
fix: correction du timeout de connexion à la base de données
feat: ajout du health check sur le endpoint /api/status
docs: mise à jour du README avec les instructions de déploiement
refactor: extraction de la logique d'authentification dans un module séparé

La convention Conventional Commits

C’est un standard très utilisé en entreprise. Le format est simple :

<type>: <description courte>

[corps optionnel — explication détaillée]

[footer optionnel — références tickets, breaking changes]

Les types les plus courants :

Type	Usage
`feat`	Nouvelle fonctionnalité
`fix`	Correction de bug
`docs`	Documentation uniquement
`style`	Formatage, pas de changement de logique
`refactor`	Restructuration du code sans changer le comportement
`test`	Ajout ou modification de tests
`chore`	Maintenance, dépendances, config
`ci`	Changements CI/CD
`perf`	Amélioration de performance

Exemple complet :

fix: correction du script de backup qui échouait silencieusement

Le script backup.sh ne vérifiait pas le code retour de rsync,
ce qui faisait que les backups incomplets étaient considérés
comme réussis. Ajout d'un check explicite avec alerte Slack
en cas d'échec.

Fixes #142

💡 Tip DevOps : Certaines équipes utilisent des outils comme commitlint pour forcer le respect de Conventional Commits via un hook Git. Si le message ne respecte pas le format, le commit est refusé. Ça peut sembler strict, mais ça garantit un historique lisible et permet de générer automatiquement des changelogs.

9. Alias Git — gagner en productivité

Pourquoi créer des alias

Tu vas taper certaines commandes Git des centaines de fois par jour. Les alias te permettent de créer des raccourcis personnalisés.

Voici les alias les plus utiles. Chaque commande git config crée un raccourci que tu pourras utiliser immédiatement :

# Raccourcis de base
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit

# Log graphique — LA commande à avoir
git config --global alias.lg "log --oneline --graph --all --decorate"

# Dernier commit
git config --global alias.last "log -1 HEAD"

# Déstaguer un fichier
git config --global alias.unstage "reset HEAD --"

# Diff des fichiers stagés
git config --global alias.staged "diff --cached"

# Log compact avec dates relatives
git config --global alias.recent "log --oneline -10 --format='%C(yellow)%h %C(green)%ar %C(reset)%s'"

Maintenant tu peux taper :

git st          # au lieu de git status
git lg          # log graphique magnifique
git last        # voir le dernier commit
git unstage fichier.txt  # retirer de la staging area
git recent      # les 10 derniers commits avec dates relatives

🔥 Cas réel en entreprise : Les développeurs seniors ont souvent des dizaines d’alias Git accumulés au fil des années. Partager sa config Git (via un repo dotfiles) est une pratique courante dans les équipes. Ça permet aux nouveaux arrivants de démarrer avec des outils optimisés dès le premier jour.

10. Résumé des commandes essentielles

Voici ta cheat sheet pour ce chapitre. Imprime-la, colle-la à côté de ton écran, fais-en ton fond d’écran — peu importe, mais garde-la sous la main.

Configuration

git config --global user.name "Nom"       # Définir ton nom
git config --global user.email "email"     # Définir ton email
git config --global core.editor "vim"      # Éditeur par défaut
git config --global init.defaultBranch main  # Branche par défaut
git config --list                          # Voir toute la config

Créer et observer

git init                    # Créer un nouveau dépôt
git status                  # État actuel du repo
git log --oneline           # Historique compact
git diff                    # Voir les changements non stagés
git diff --staged           # Voir les changements stagés

Le cycle fondamental

git add <fichier>           # Stager un fichier
git add .                   # Stager tout
git commit -m "message"     # Commiter
git commit --amend          # Modifier le dernier commit

Annuler

git restore <fichier>       # Annuler les modifs (non stagées)
git restore --staged <f>    # Déstaguer un fichier
git checkout <hash>         # Consulter un ancien commit

À toi de jouer

Exercice 1 — Installation et configuration complète

Installe Git sur ta machine et effectue une configuration complète :

# 1. Installe Git (adapte à ton OS)
sudo apt install git-all  # ou brew install git

# 2. Configure ton identité
git config --global user.name "Ton Nom"
git config --global user.email "ton@email.com"

# 3. Configure les préférences
git config --global core.editor "vim"
git config --global init.defaultBranch main
git config --global color.ui auto
git config --global core.autocrlf input

# 4. Vérifie
git config --list

Critère de réussite : git config --list affiche tes informations correctement.

Exercice 2 — Crée ton premier dépôt et fais 3 commits

# 1. Crée un projet
mkdir mon-projet-devops && cd mon-projet-devops
git init

# 2. Premier commit
echo "# Mon Projet DevOps" > README.md
git add README.md
git commit -m "Initial commit: ajout du README"

# 3. Deuxième commit
echo "*.log" > .gitignore
echo ".env" >> .gitignore
git add .gitignore
git commit -m "chore: ajout du .gitignore"

# 4. Troisième commit
echo '#!/bin/bash' > deploy.sh
echo 'echo "Deploying..."' >> deploy.sh
chmod +x deploy.sh
git add deploy.sh
git commit -m "feat: ajout du script de déploiement"

# 5. Vérifie l'historique
git log --oneline

Critère de réussite : git log --oneline affiche 3 commits avec des messages clairs.

Exercice 3 — Explore les états et les diffs

Cet exercice te fait pratiquer la boucle status → diff → add → commit :

Modifie README.md — ajoute une section ”## Installation”
Lance git status — observe l’état “modified”
Lance git diff — observe les changements
Crée un fichier notes.txt avec du contenu
Lance git status — observe “modified” ET “untracked”
Stage uniquement README.md avec git add README.md
Lance git status — observe un fichier “staged” et un “untracked”
Lance git diff --staged — observe les changements prêts à commiter
Commite avec un message Conventional Commits
Stage et commite notes.txt séparément

Critère de réussite : Tu comprends la différence entre git diff et git diff --staged, et tu sais stager des fichiers sélectivement.

Exercice 4 — Annulation et amend

Modifie deploy.sh — ajoute une ligne
Annule la modification avec git restore deploy.sh
Vérifie avec git status que le fichier est propre
Fais un commit avec une faute dans le message
Corrige le message avec git commit --amend -m "message corrigé"
Vérifie avec git log --oneline

Critère de réussite : Tu sais annuler des modifications et corriger un commit.

➡️ La suite

Dans le prochain chapitre, on passe aux branches — le concept qui fait toute la puissance de Git. Tu apprendras à travailler sur plusieurs versions de ton projet en parallèle, à fusionner du code, et à gérer les conflits. C’est là que Git devient vraiment fun.

En attendant, pratique les commandes de ce chapitre jusqu’à ce qu’elles deviennent des réflexes. status, add, commit, log, diff — ces cinq commandes représentent 80% de ton utilisation quotidienne de Git.

🧠 À retenir : Git s’apprend en pratiquant, pas en lisant. Ouvre un terminal, crée un repo de test, et expérimente. Casse des trucs. Reviens en arrière. C’est littéralement fait pour ça.