Nettoyer l'historique et les fichiers Git

Le fichier est dans .gitignore mais Git le suit toujours ? Vous avez commité un secret ? Votre repo fait des centaines de Mo à cause d’un binaire ? Ce guide couvre les trois problèmes de nettoyage les plus fréquents : arrêter de suivre un fichier, purger des données sensibles de tout l’historique, et réduire la taille d’un dépôt.

Prérequis : Enregistrer des modifications et Réécrire l’historique.

Ce que vous allez apprendre

Arrêter de suivre un fichier sans le supprimer du disque
Supprimer un fichier sensible de tout l’historique avec git filter-repo
Appliquer le bon workflow selon que le secret est local ou déjà poussé
Déboguer .gitignore quand un fichier continue d’être tracké malgré la règle

Diagnostic rapide : quel est votre problème ?

Symptôme	Cause	Section
Fichier dans `.gitignore` mais suivi par Git	Ajouté avant le `.gitignore`	« Arrêter de suivre un fichier »
`.gitignore` ne semble pas fonctionner	Erreur de syntaxe ou de priorité	« Débugger un .gitignore »
Secret/mot de passe commité par erreur	Visibles dans l’historique	« Supprimer un secret de l’historique »
Dépôt volumineux (> 100 Mo)	Fichier binaire dans l’historique	« Réduire la taille du dépôt »

Arrêter de suivre un fichier

Vous avez ajouté config/local.json au repo avant de mettre la règle dans .gitignore. Le fichier est ignoré pour les futures modifications, mais Git le suit toujours car il est dans l’index.

git rm --cached config/local.json

--cached retire le fichier de l’index (Git arrête de le suivre) sans le supprimer du disque. Le fichier reste dans votre répertoire de travail.

Commitez le changement :

git commit -m "chore: arrêter de suivre config/local.json"

Vérification :

git status
# config/local.json ne doit plus apparaître

Pour un dossier entier :

git rm -r --cached node_modules/
git commit -m "chore: arrêter de suivre node_modules"

Débugger un .gitignore

Le .gitignore ne fonctionne pas comme attendu ? Utilisez git check-ignore pour comprendre pourquoi :

Vérifier si un fichier est ignoré

git check-ignore -v config/local.json

Sortie si le fichier est ignoré :

.gitignore:3:config/*.json    config/local.json

Cela indique quelle règle (fichier, ligne) cause l’ignorance. Si aucune sortie, le fichier n’est pas ignoré.

Règles de priorité du .gitignore

Quand plusieurs règles s’appliquent, la dernière règle gagne :

# Ignorer tous les logs
*.log

# MAIS garder error.log
!error.log

Règle	Signification
`*.log`	Ignore tous les fichiers `.log`
`!error.log`	Négation — force le suivi de `error.log`
`logs/`	Ignore le dossier `logs` et tout son contenu
`logs/*.log`	Ignore les `.log` dans `logs/` (pas les sous-dossiers)
`logs/*/.log`	Ignore les `.log` dans `logs/` et tous ses sous-dossiers

Erreurs fréquentes

# ❌ Ne fonctionne pas : le fichier est déjà suivi
secret.env

# ✅ Solution : d'abord git rm --cached, puis ajouter la règle

# ❌ La négation ne fonctionne pas si le dossier parent est ignoré
build/
!build/important.js

# ✅ Solution : ignorer le contenu, pas le dossier
build/*
!build/important.js

Lister tous les fichiers ignorés

git status --ignored

Supprimer un secret de tout l’historique

Un mot de passe, une clé API ou un token a été commité. Même si vous le supprimez dans un nouveau commit, il reste visible dans l’historique. Voici le workflow complet.

Installez git-filter-repo

git-filter-repo remplace l’ancien filter-branch (plus sûr, plus rapide). Installez-le :
Fenêtre de terminal
```
pip install git-filter-repo
```
Vérification :
Fenêtre de terminal
```
git filter-repo --version
```
Sauvegardez votre repo (par sécurité)
Fenêtre de terminal
```
cp -r mon-projet mon-projet-backup
```
Supprimez le fichier de tout l’historique
Fenêtre de terminal
```
git filter-repo --path .env --invert-paths
```
--invert-paths signifie : « supprime tout ce qui correspond au path donné ». Le fichier .env disparaît de tous les commits.

Vérifiez que le fichier n’apparaît plus

git log --all --full-history -- .env
# Aucun résultat = le fichier est purgé

Ajoutez le fichier au .gitignore

echo ".env" >> .gitignore
git add .gitignore
git commit -m "chore: ajouter .env au gitignore"

Force push vers le remote
Vérifiez avant de force push
Un git push --force réécrit l’historique sur le serveur. Une fois poussé, les collègues qui ont déjà cloné le repo ne pourront plus pusher normalement — ils devront re-cloner ou faire un git reset --hard. Confirmez que :
- Votre backup local (mon-projet-backup) est bien présent
- git log --all --full-history -- .env ne retourne rien
- Vous avez prévenu votre équipe avant de pusher
Fenêtre de terminal
```
git push --force --all
git push --force --tags
```
Prévenez votre équipe

Tous les collègues doivent re-cloner ou exécuter :
Fenêtre de terminal
```
git fetch --all
git reset --hard origin/main
```

Supprimer un texte spécifique (pas un fichier entier)

Si le secret est une ligne à l’intérieur d’un fichier (pas le fichier entier) :

git filter-repo --replace-text <(echo 'MON_SECRET_123==>***REDACTED***')

Cela remplace toutes les occurrences de MON_SECRET_123 par ***REDACTED*** dans tous les fichiers de tout l’historique.

Réduire la taille du dépôt

Un fichier binaire volumineux (dump SQL, vidéo, archive) a été commité et gonfle le repo :

Identifier les gros fichiers

git rev-list --objects --all \
  | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \
  | awk '/^blob/ {print $3, $4}' \
  | sort -rn \
  | head -20

Sortie :

52428800 data/dump.sql
10485760 assets/video-demo.mp4

Supprimer les gros fichiers de l’historique

git filter-repo --path data/dump.sql --invert-paths

Prévenir avec Git LFS

Pour éviter que cela ne se reproduise, utilisez Git LFS (Large File Storage) pour les fichiers volumineux :

git lfs install
git lfs track "*.sql"
git lfs track "*.mp4"
git add .gitattributes
git commit -m "chore: configurer Git LFS pour SQL et vidéos"

Dépannage : problèmes courants

Symptôme	Cause probable	Solution
`.gitignore` ne fonctionne pas	Fichier déjà suivi (dans l’index)	`git rm --cached fichier` d’abord
`filter-repo` refuse de s’exécuter	Repo pas « fresh clone »	Ajoutez `--force` ou reclonez
Le repo est toujours gros après `filter-repo`	Objets non collectés	`git reflog expire --expire=now --all && git gc --prune=now --aggressive`
Les collègues ont des erreurs après le force push	Historiques divergents	Ils doivent re-cloner ou `git fetch --all && git reset --hard origin/main`
La négation `!fichier` dans `.gitignore` ne marche pas	Le dossier parent est ignoré avec `/`	Ignorer le contenu `dossier/*` au lieu du dossier `dossier/`

À retenir

git rm --cached arrête de suivre un fichier sans le supprimer du disque
.gitignore ne s’applique qu’aux fichiers non encore suivis — d’abord rm --cached, puis .gitignore
git check-ignore -v est l’outil de debug du .gitignore
Secret commité = secret compromis — changez-le immédiatement, avant le nettoyage Git
git filter-repo supprime un fichier de tout l’historique (remplace filter-branch)
Après un filter-repo, il faut force push et prévenir l’équipe
Git LFS prévient le problème des gros fichiers en les stockant séparément

Prochaines étapes

Récupérer des données perdues Reflog, branches supprimées, reset --hard : retrouvez ce que vous croyez perdu.

Réécrire l'historique Rebase interactif, squash, fixup et filter-repo en détail.

Rechercher dans Git git grep, log -S, log -G : trouvez n'importe quoi dans le code ou l'historique.