Versioning avec Git & GitHub · Étape 10

Maîtrise gitignore, les fichiers suivis et les secrets

Écris des règles d’ignore vérifiables, arrête de suivre un fichier généré et distingue prévention, retrait et rotation d’un secret.

Durée indicative · ~1 h 35Niveau intermédiairePrérequis conseillé · Leçon 9 — récupération avec reflogPratique · TP
L’idée reçue

« Ajouter un fichier à .gitignore le retire de l’historique. »

Les règles d’ignore concernent les fichiers non suivis. Un fichier déjà suivi continue d’être versionné jusqu’à une action explicite.

01Observe les règles

cd /tmp/soria-git-undo-$USER/ignore-secrets
cat .gitignore
git status --ignored --short
git check-ignore -v .env logs/app.log config/runtime.env

git check-ignore -v indique la règle et le fichier qui expliquent l’ignore.

02Vérifie le fichier déjà suivi

git ls-files config/runtime.env
git status --short

Malgré la nouvelle règle, config/runtime.env reste suivi parce qu’il était présent dans un commit antérieur.

03Arrête le suivi sans supprimer le fichier local

git rm --cached config/runtime.env
git status --short
test -f config/runtime.env && echo "local file preserved"
git commit -m "chore: stop tracking generated runtime environment"

Le commit retire le fichier de l’état versionné. La copie locale reste présente et devient ignored.

04Distingue modèle et secret

config/app.env.example   suivi, sans valeur sensible
.env                     local, ignored
secrets/                 local ou géré par un coffre, ignored
logs/*.log               généré, ignored

Le dépôt conserve la structure attendue et des valeurs fictives. Les secrets réels proviennent d’un gestionnaire de secrets ou de variables d’environnement protégées.

05Recherche une valeur fictive

git grep 'TRAINING_TOKEN' || true
git log -S 'TRAINING_TOKEN' --all --oneline
git rev-list --all --objects | head

Le lab exige que la valeur fictive du fichier .env n’apparaisse dans aucun commit.

06Réagis à un secret réellement exposé

1. Révoquer ou faire tourner immédiatement le secret.
2. Identifier dépôts, branches, tags, forks, caches et logs concernés.
3. Retirer la valeur du code courant.
4. Choisir une réécriture d’historique seulement avec coordination.
5. Forcer la mise à jour des clones et vérifier les protections.
6. Documenter l’incident et empêcher sa répétition.

Revert ou suppression du fichier courant ne rendent pas un secret déjà publié à nouveau sûr. La rotation reste prioritaire.

07Teste les motifs

printf 'debug.log\n.env\nconfig/runtime.env\nREADME.md\n' |
  git check-ignore --stdin -v

Teste les règles avant commit pour éviter un motif trop large qui masquerait des fichiers utiles.

Projet du lot 2

Produis un dossier d’annulation et de sécurité

Démontre restore, soft/mixed/hard reset, revert, récupération reflog et arrêt du suivi d’un fichier ignored. Pour chaque opération, fournis état avant, commande, état après, risque et cas d’usage.

Lot 2 terminé

Tu sais annuler localement, préserver un historique partagé, récupérer un commit perdu et empêcher les fichiers sensibles ou générés d’entrer dans les futurs commits.

Ta progression

Chargement de l’état… Se connecter pour synchroniser.