1.1 Le cauchemar des fichiers "Final"

On a tous déjà vécu ça. Vous travaillez sur un projet important, vous avez peur de perdre des modifications ou de faire une bêtise, alors vous faites des copies. Et ça finit comme ça :

1.2 Travailler en équipe sans s'entretuer

Imaginez maintenant que vous êtes 3 à travailler sur le MÊME fichier en même temps.

• Comment fusionner les modifications d'Alice avec celles de Bob ?
• Que se passe-t-il si les deux modifient la ligne 12 en même temps ?
• Comment savoir qui a cassé le code hier soir ?

Sans outil adapté, c'est le chaos assuré. On s'envoie des fichiers par mail "tiens ma version", on écrase le travail des autres par erreur...

2.1 La machine à remonter le temps

Git est un logiciel de gestion de versions (VCS). Pour faire simple, c'est une "machine à remonter le temps" pour vos dossiers.

2.2 "Distribué", ça veut dire quoi ?

Vous entendrez souvent que Git est "décentralisé" ou "distribué". Contrairement à une sauvegarde classique sur un serveur central :

Avantage énorme : Vous pouvez travailler dans le train, sans internet. Vous avez votre propre copie complète de la base de données du projet. Vous pouvez faire des commits, créer des branches, regarder l'historique... tout ça hors ligne !

3.1 Installer Git facilement

git --version

3.2 La première configuration (Indispensable !)

Une fois Git installé, vous devez lui dire qui vous êtes. Ces informations apparaîtront dans l'historique de chaque modification.

3.3 Git vs GitHub (Ne pas confondre !)

C'est la confusion n°1 des débutants.

1.1 Démarrer un projet Git

Pour commencer à suivre l'historique d'un projet, il faut dire à Git : "Hé, surveille ce dossier !". C'est le rôle de la commande git init.

# 1. Se placer dans le dossier du projet
$ cd mon-super-projet

# 2. Initialiser Git
$ git init
Initialized empty Git repository in /chemin/mon-super-projet/.git/

1.2 Que s'est-il passé ?

Si vous regardez les fichiers (en affichant les éléments masqués), vous verrez un nouveau dossier caché : .git.

2.1 Le dossier .git : Touche pas à ça !

Le dossier .git est le cerveau de votre projet. Il contient tout votre historique, tous vos anciens fichiers, toutes vos branches.

Si vous supprimez ce dossier, vous perdez tout l'historique du projet et redevenez un simple dossier de fichiers.

2.2 Analogie : L'album photo

Imaginez Git comme un photographe ultra-rapide pour votre code.

3.1 Empreintes digitales (Hash)

Git donne à chaque version de fichier et à chaque commit une empreinte digitale unique. C'est une suite de 40 caractères bizarres (lettres et chiffres) que vous verrez souvent.

a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0

On appelle ça un SHA-1 (ou Hash). Ce qu'il faut retenir :

• Si vous changez une seule virgule dans un fichier, son empreinte change complètement.
• C'est impossible de corrompre un fichier sans que Git ne s'en aperçoive.
• C'est grâce à ça que Git est ultra-fiable pour le travail en équipe.

1.1 Le Repository et le Commit

1.2 Les 4 États d'un fichier

Git classe chaque fichier de votre dossier dans une de ces 4 catégories. C'est CRUCIAL de bien comprendre la différence.

2.1 La commande git add

git add sert à passer un fichier de l'état Untracked ou Modified à l'état Staged.

# Ajouter un seul fichier
$ git add index.html

# Ajouter plusieurs fichiers spécifiques
$ git add style.css script.js

# Ajouter tout un dossier
$ git add images/

# ⚡ Ajouter TOUT (nouveaux, modifiés, supprimés) - Le plus utilisé
$ git add .

# Ajouter tout (alternative, pareil que .)
$ git add -A

2.2 Le fichier .gitignore

Certains fichiers ne doivent JAMAIS être committés (mots de passe, fichiers temporaires, dossiers de build, dépendances lourdes...). Pour ça, on crée un fichier texte nommé .gitignore à la racine.

# Ignorer un fichier spécifique
secret.txt
.env

# Ignorer par extension
*.log
*.tmp
*.psd

# Ignorer un dossier complet
node_modules/
vendor/
build/

# Ignorer tout sauf...
!index.html

3.1 git status (Le tableau de bord)

Affiche l'état actuel de votre Working Directory et de votre Staging Area.

$ git status

Untracked files:
  (use "git add ..." to include in what will be committed)
    nouveau_fichier.txt

Changes to be committed:
  (use "git restore --staged ..." to unstage)
    new file:   style.css
    modified:   index.html

3.2 git commit (La validation)

Crée une nouvelle version avec tout ce qui est dans la Staging Area.

$ git commit -m "Message clair et concis"

$ git commit -a -m "Message rapide"

$ git commit -am "Ajoute et commit les modifs en une fois"

1.1 La base et les variantes d'affichage

La commande git log est votre fenêtre sur le passé. Par défaut, elle est verbeuse, mais on peut la personnaliser à l'infini.

1.2 Filtrer la recherche

Dans un projet avec 10 000 commits, vous devez savoir chercher.

git log --since="2024-01-01"

git log --until="2 weeks ago"

git log --author="Oussama"

git log --grep="bugfix"

git log -- index.html

2.1 Comprendre ce qu'on compare

git diff ne sert pas juste à voir ce qu'on a fait avant de commiter. C'est un outil de comparaison universel.

$ git diff

$ git diff --staged

$ git diff a1b2c..d4e5f

$ git diff main..feature

3.1 La commande aux multiples visages

git checkout fait deux choses très différentes selon le contexte. C'est pour cela que Git moderne a introduit switch et restore (mais checkout reste universel).

# Aller sur une branche
$ git checkout main

# Créer et aller sur une branche
$ git checkout -b ma-super-branche

# Aller sur un commit précis (Lecture seule)
$ git checkout a1b2c3d

# Annuler les modifs d'un fichier
$ git checkout -- fichier.html

# Tout remettre à zéro (DANGER ☢️)
$ git checkout .

# Récupérer un fichier d'une autre branche
$ git checkout main -- fichier.html

1.1 Corriger le dernier commit

Vous venez de commiter et... vous réalisez que vous avez fait une faute de frappe dans le message ? Ou oublié un fichier ?

Pas besoin de créer un commit "Oups correction" ! Utilisez --amend pour modifier le commit précédent comme si rien ne s'était passé.

# Cas 1 : Changer juste le message
$ git commit --amend -m "Nouveau message corrigé"

# Cas 2 : Ajouter un fichier oublié
$ git add fichier_oublie.css
$ git commit --amend --no-edit
# --no-edit garde l'ancien message

2.1 Le concept : "L'Anti-Commit"

Imaginez que vous avez ajouté une fonctionnalité qui fait planter le site en Prod. Vous voulez l'annuler, MAIS vous ne voulez pas effacer l'historique (pour garder une trace de l'erreur).

git revert ne supprime pas de commit. Il crée un Nouveau Commit qui fait exactement l'inverse du commit ciblé.

# Annuler le dernier commit
$ git revert HEAD

# Annuler un commit spécifique (via son hash)
$ git revert a1b2c3d

3.1 Le Grand Nettoyage

Contrairement à Revert, git reset efface l'historique. Il déplace le pointeur HEAD vers l'arrière, comme si les commits suivants n'avaient jamais existé.

Les 3 Modes de Reset (Le Trio Infernal)

4.1 Le remplaçant moderne de checkout

Comme nous l'avons vu, git checkout fait trop de choses. Git a introduit git restore spécifiquement pour gérer les fichiers, sans risque de changer de branche par erreur.

$ git restore mon_fichier.txt

$ git restore --staged mon_fichier.txt

1.1 Le concept de Branche (Mondes Parallèles)

Une branche est une ligne de développement indépendante. Elle permet de travailler sur une fonctionnalité ou un correctif sans toucher à la version stable (souvent appelée main ou master) du projet.

C'est comme faire une photocopie d'un document pour écrire des notes dessus. Si les notes sont mauvaises, on jette la photocopie. Si elles sont bonnes, on les recopie sur l'original.

1.2 Voir l'Invisible avec Ungit

2.1 Créer et Changer (Branch, Checkout, Switch)

# Créer une branche
$ git branch ma-feature

# Aller dessus
$ git checkout ma-feature

# Créer ET Aller dessus (Raccourci)
$ git checkout -b ma-feature

# Aller sur une branche existante
$ git switch ma-feature

# Créer ET Aller dessus
$ git switch -c ma-feature

2.2 ramener le travail (Merge)

Une fois le travail fini sur la branche, il faut le ramener sur la branche principale.

# 1. Je retourne sur le vaisseau mère
$ git switch main

# 2. J'aspire le travail de ma branche
$ git merge ma-feature

3.1 Initialisation (Main)

Créez le dossier techstore et les fichiers suivants. Commitez le tout sur main.

<!DOCTYPE html><html><body><h1>TechStore</h1></body></html>

body { background: #fff; color: #333; }

<!DOCTYPE html><html><body><h1>TechStore</h1></body></html>

body { background: #fff; color: #333; }

3.2 Cas 1 : Le Fast-Forward (Design)

Vous travaillez seul. main ne bouge pas. C'est le cas le plus simple.

1. Créez une branche : git switch -c design-v2
2. Modifiez style.css (Changez le background en #f4f4f4).
3. Commitez :

   $ git add .

   $ git commit -m "New Design"

4. Revenez sur main : git switch main
5. Fusionnez : git merge design-v2

Observe le résultat : Git a juste avancé l'étiquette main. C'est un Fast-Forward.

3.3 Cas 2 : L'Historique Forcé (Features)

On veut voir clairement la branche "Produits" dans l'historique, même si un FF est possible.

1. Branche : git switch -c feature-produits
2. Créez produits.html. Commitez :

   $ git add .

   $ git commit -m "Page produits basic"

3. Main : git switch main
4. Fusion : git merge --no-ff feature-produits

Observe Ungit : Une "bulle" s'est créée. On voit le début et la fin de la feature.

4.1 Le "Presse-papiers" de Git

Vous devez changer de branche MAIS votre travail n'est pas fini. Vous ne pouvez pas commiter du code cassé.
Le Stash vous permet de stocker temporairement vos fichiers modifiés.

1.1 Qu'est-ce qu'un serveur Git ? (Bare Repo)

Avant de parler de GitHub ou GitLab, comprenez ceci : pour qu'un dépôt serve de "Serveur Central" où tout le monde pousse son code, il ne doit pas avoir de dossier de travail (Working Directory).

Pourquoi ? Si je pousse mon code sur un serveur qui a des fichiers ouverts, je risque de corrompre le travail en cours sur le serveur. C'est pour cela qu'on utilise --bare.

2.1 Envoyer ses modifications (Push)

Une fois vos commits effectués localement, ils ne sont pas encore sur le serveur. Pour les transférer, on utilise push.

Si c'est la première fois, Git vous demandera peut-être de définir la branche amont (upstream) avec -u.

2.2 Récupérer les nouveautés (Pull Standard)

Pour récupérer le travail de vos collègues, la commande standard est pull.

Ce que ça fait vraiment : Git télécharge les nouveautés ET essaie de les fusionner (Merge) avec votre travail actuel.

2.4 L'élégance du Pull --rebase

Par défaut, si vous et votre collègue avez travaillé en même temps, git pull va créer un "Commit de Fusion" qui peut polluer l'historique.

L'alternative Pro : Utiliser --rebase. Git va : 1. Mettre vos commits locaux de côté. 2. Mettre à jour avec le code du serveur. 3. Ré-appliquer vos commits à la suite.

3.1 Choisir son Camp (Ours vs Theirs)

Parfois, vous ne voulez pas déchiffrer les chevrons <<< et >>>. Vous savez que vous voulez juste "MA version" ou "LEUR version".

1.1 Retrouver l'auteur d'une ligne

git blame affiche, pour chaque ligne d'un fichier, qui l'a modifiée en dernier, quand, et dans quel commit.

# Blame un fichier entier
$ git blame src/app.js

# Sortie exemple :
abc1234d (Alice   2024-01-15 10:30:00 +0100  1) const express = require('express');
def5678e (Bob     2024-02-20 14:45:00 +0100  2) const app = express();
abc1234d (Alice   2024-01-15 10:30:00 +0100  3)
ghi9012f (Charlie 2024-03-10 09:15:00 +0100  4) app.use(cors());

# Blame une plage de lignes spécifique
$ git blame -L 10,20 src/app.js

# Ignorer les espaces blancs
$ git blame -w src/app.js

# Format court (juste le hash)
$ git blame -s src/app.js

# Afficher l'email au lieu du nom
$ git blame -e src/app.js

1.2 Ignorer certains commits

Parfois un commit de reformatage pollue le blame. Git permet de l'ignorer.

# Ignorer un commit spécifique
$ git blame --ignore-rev abc1234 src/app.js

# Ignorer une liste de commits (fichier)
$ echo "abc1234" >> .git-blame-ignore-revs
$ echo "def5678" >> .git-blame-ignore-revs
$ git blame --ignore-revs-file .git-blame-ignore-revs src/app.js

# Configurer le fichier globalement pour le projet
$ git config blame.ignoreRevsFile .git-blame-ignore-revs

2.1 Chasse aux bugs par dichotomie

git bisect utilise une recherche binaire pour trouver le commit exact qui a introduit un bug. Extrêmement efficace sur les longs historiques.

# 1. Démarrer la session bisect
$ git bisect start

# 2. Marquer le commit actuel comme "mauvais" (bug présent)
$ git bisect bad

# 3. Marquer un ancien commit comme "bon" (bug absent)
$ git bisect good v1.0.0
# ou: git bisect good abc1234

# 4. Git checkout un commit au milieu
# Testez si le bug est présent...

# 5. Marquer selon le résultat
$ git bisect good    # Bug absent
# ou
$ git bisect bad     # Bug présent

# 6. Répéter jusqu'à trouver le commit coupable
# Git affiche: "abc1234 is the first bad commit"

# 7. Terminer et revenir à l'état initial
$ git bisect reset

2.2 Bisect automatisé avec un script

Si vous avez un test automatisé, Git peut exécuter le bisect sans intervention humaine :

# Script de test (doit retourner 0 = good, 1-127 = bad, 125 = skip)
$ cat test-bug.sh
#!/bin/bash
npm test 2>&1 | grep -q "PASS"
# Retourne 0 si "PASS" trouvé, sinon retourne 1

# Lancer le bisect automatique
$ git bisect start
$ git bisect bad HEAD
$ git bisect good v1.0.0
$ git bisect run ./test-bug.sh

# Git teste automatiquement chaque commit et trouve le coupable

3.1 Recherche dans le code versionné

git grep est un grep optimisé pour les dépôts Git. Plus rapide que grep classique et ignore automatiquement .git/ et les fichiers ignorés.

# Recherche simple
$ git grep "TODO"

# Ignorer la casse
$ git grep -i "error"

# Afficher les numéros de ligne
$ git grep -n "function"

# Compter les occurrences par fichier
$ git grep -c "import"

# Recherche avec contexte (3 lignes avant/après)
$ git grep -C 3 "bug"

# Limiter à certains fichiers
$ git grep "useState" -- "*.jsx" "*.tsx"

# Expression régulière étendue
$ git grep -E "TODO|FIXME|HACK"

3.2 Recherche dans l'historique

Contrairement à grep classique, git grep peut chercher dans les anciennes versions du code :

# Chercher dans un commit spécifique
$ git grep "oldFunction" abc1234

# Chercher dans un tag
$ git grep "deprecated" v1.0.0

# Chercher dans toutes les branches
$ git grep "API_KEY" $(git branch -r --format='%(refname:short)')

# Chercher quand un pattern a été ajouté/supprimé
$ git log -p -S "function login" --all

# Avec expression régulière
$ git log -p -G "function\s+login\s*\(" --all

1.1 Git Submodules

Un submodule est un dépôt Git imbriqué dans un autre dépôt. Le parent stocke une référence vers un commit spécifique du submodule.

# Ajouter un submodule
$ git submodule add https://github.com/lib/library.git libs/library

# Cloner un projet avec submodules
$ git clone --recurse-submodules https://github.com/user/project.git
# ou après clone :
$ git submodule update --init --recursive

# Mettre à jour tous les submodules
$ git submodule update --remote

# Voir le statut des submodules
$ git submodule status

1.2 Git Subtrees

Un subtree intègre directement le code d'un autre dépôt. Pas de références externes — tout est dans l'historique.

# Ajouter un subtree
$ git subtree add --prefix=libs/library https://github.com/lib/library.git main --squash

# Mettre à jour depuis l'upstream
$ git subtree pull --prefix=libs/library https://github.com/lib/library.git main --squash

# Pousser des modifications vers l'upstream
$ git subtree push --prefix=libs/library https://github.com/lib/library.git feature-branch

2.1 GitFlow

main        ●──────────────────●────────────────●
             ↑                  ↑                ↑
release     ┃    ●─────────────●                ┃
             ┃   ↑              ↓                ┃
develop    ●─●───●──●──────────●───●──●─────────●
            ↑   ↑              ↑      ↑
feature-A  ●───●              ┃      ┃
                               ┃      ┃
feature-B                     ●──────●

2.2 GitHub Flow

main      ●────●────●────●────●────●
           ↑    ↑    ↑    ↑
feature   ●────●    ┃    ┃
                    ●────●

1. Créer une branche depuis main
2. Commiter et pousser régulièrement
3. Ouvrir une Pull Request pour review
4. Discuter et réviser le code
5. Déployer depuis la branch (optionnel)
6. Merger dans main et déployer

3.1 Comparaison

4.1 Git Worktrees

Permet d'avoir plusieurs branches checkout simultanément dans des dossiers séparés, partageant le même dépôt .git.

# Créer un worktree pour une branche existante
$ git worktree add ../project-hotfix hotfix/urgent-bug

# Créer un worktree avec nouvelle branche
$ git worktree add -b feature/new ../project-feature main

# Lister les worktrees
$ git worktree list
/home/user/project        abc1234 [main]
/home/user/project-hotfix def5678 [hotfix/urgent-bug]

# Supprimer un worktree
$ git worktree remove ../project-hotfix

4.2 Git Archive

Exporte une version propre du projet (sans .git) pour distribution ou déploiement.

# Créer une archive ZIP
$ git archive --format=zip --output=release-v1.0.0.zip v1.0.0

# Créer une archive tar.gz
$ git archive --format=tar.gz --output=release.tar.gz HEAD

# Archiver seulement un sous-dossier
$ git archive --format=zip --output=docs.zip HEAD:docs/

# Avec un préfixe de dossier
$ git archive --prefix=myproject-1.0/ -o release.zip v1.0.0

1.1 Diagnostiquer un dépôt corrompu

# Vérifier l'intégrité du dépôt
$ git fsck --full
error: object abc1234: badTimezone: invalid author/committer line
dangling commit def5678
missing blob ghi9012

# Identifier les problèmes
$ git fsck --lost-found
# Les objets récupérables sont placés dans .git/lost-found/

1.2 Récupération d'urgence

# Option 1 : Si le remote est sain, recloner
$ mv projet projet-backup
$ git clone https://github.com/user/projet.git

# Option 2 : Récupérer les refs corrompues depuis le remote
$ git fetch origin
$ git reset --hard origin/main

# Option 3 : Récupérer des objets manquants
$ git fetch --all
$ git fsck --full    # Revérifier

# Option 4 : Si le reflog est intact, revenir à un état sain
$ git reflog
$ git reset --hard HEAD@{5}

2.1 Le problème : Fichier sensible commité

Étape 0 : Révoquez immédiatement les secrets exposés (nouvelle clé API, nouveau mot de passe, etc.)

2.2 BFG Repo-Cleaner (Recommandé)

Outil dédié, beaucoup plus rapide et simple que git filter-branch.

# Installation (Java requis)
# Télécharger depuis https://rtyley.github.io/bfg-repo-cleaner/

# Supprimer un fichier de tout l'historique
$ java -jar bfg.jar --delete-files .env repo.git

# Supprimer les fichiers > 100Mo
$ java -jar bfg.jar --strip-blobs-bigger-than 100M repo.git

# Remplacer du texte (mots de passe)
$ echo "PASSWORD" > passwords.txt
$ java -jar bfg.jar --replace-text passwords.txt repo.git

# Après BFG, nettoyer les objets
$ cd repo.git
$ git reflog expire --expire=now --all
$ git gc --prune=now --aggressive

# Force push le résultat
$ git push --force --all
$ git push --force --tags

3.1 Qu'est-ce qu'un Hook Git ?

Les hooks sont des scripts exécutés automatiquement à certains moments du cycle Git. Ils vivent dans .git/hooks/.

3.2 Exemple : Hook pre-commit

#!/bin/sh
# .git/hooks/pre-commit

# Linter JavaScript
echo "🔍 Running ESLint..."
npx eslint --fix .
if [ $? -ne 0 ]; then
    echo "❌ ESLint failed. Commit aborted."
    exit 1
fi

# Vérifier qu'aucun fichier sensible n'est stagé
if git diff --cached --name-only | grep -E '\.(env|pem|key)$'; then
    echo "❌ Sensitive file detected! Commit aborted."
    exit 1
fi

echo "✅ Pre-commit checks passed!"
exit 0

# Rendre le hook exécutable
$ chmod +x .git/hooks/pre-commit

# Bypasser un hook (urgence seulement)
$ git commit --no-verify -m "Emergency fix"

4.1 Pourquoi signer ses commits ?

4.2 Configuration de la signature

# 1. Générer une clé GPG (ou utiliser une existante)
$ gpg --full-generate-key
# Choisir RSA 4096, email identique à git config user.email

# 2. Trouver l'ID de votre clé
$ gpg --list-secret-keys --keyid-format LONG
sec   rsa4096/3AA5C34371567BD2 2024-01-01 [SC]
#                ↑ C'est l'ID de la clé

# 3. Configurer Git
$ git config --global user.signingkey 3AA5C34371567BD2
$ git config --global commit.gpgsign true    # Signe tous les commits
$ git config --global tag.gpgsign true       # Signe tous les tags

# 4. Exporter la clé publique (pour GitHub/GitLab)
$ gpg --armor --export 3AA5C34371567BD2

4.3 Utilisation

# Signer un commit (si gpgsign n'est pas activé globalement)
$ git commit -S -m "Signed commit"

# Signer un tag
$ git tag -s v1.0.0 -m "Signed release"

# Vérifier la signature d'un commit
$ git verify-commit abc1234
$ git log --show-signature

# Vérifier la signature d'un tag
$ git verify-tag v1.0.0

📚 Pour aller plus loin