Hygiène d'un dépôt

Un dépôt se dégrade par accumulation : des fichiers qui n'auraient jamais dû entrer, des secrets oubliés, des archives qui alourdissent chaque clonage. Rien de tout cela ne se corrige facilement après coup — l'historique est justement fait pour ne pas oublier.

Ignorer ce qui n'a pas sa place

node_modules/          # dépendances : réinstallables
.env                   # configuration locale et secrets
*.log                  # bruit
.next/                 # sortie de build

La règle est simple : ce qui est régénérable ou local n'entre pas. Le code et la configuration d'exemple entrent ; les dépendances, les artefacts de build et les secrets, non.

Un secret commité est un secret compromis

C'est le point à comprendre avant tout autre. Retirer un secret de l'historique ne suffit jamais, pour une raison qui n'a rien de technique : dès qu'il a été poussé, il est présent dans chaque clone déjà effectué, dans les caches de la forge, éventuellement dans des sauvegardes et des journaux de chaîne de livraison.

L'ordre des opérations est donc :

1. révoquer la clé et en émettre une nouvelle — c'est l'étape qui protège réellement ;
2. purger l'historique (git filter-repo) et forcer la réécriture, ce qui réécrit tout et impose à chacun de recloner ;
3. ajouter le fichier au .gitignore et poser un contrôle automatique pour la suite.

Inverser 1 et 2 est l'erreur habituelle : on passe des heures à nettoyer un historique pendant que la clé, toujours valide, reste exploitable.

Les gros fichiers ne partent jamais

Un binaire de 200 Mo commité une fois reste dans la base d'objets pour toujours : chaque clonage, y compris celui de la chaîne de livraison, le télécharge. Le supprimer dans un commit ultérieur n'y change rien — le blob est dans un instantané passé.

D'où l'usage de Git LFS pour les fichiers volumineux, et la règle : un dépôt contient du texte versionnable, pas des artefacts. Les artefacts vont dans un registre — c'est exactement le propos de Concevoir une pipeline robuste.

Étiqueter une version

git tag -a v1.2.0 -m "Version 1.2.0"      # annotée : auteur, date, message
git push --tags

Une étiquette annotée est un objet à part entière, et c'est la seule forme correcte pour une version publiée : elle est datée, signée si tu le souhaites, et traçable. Les étiquettes ne partent pas au push ordinaire — c'est ainsi qu'une version reste invisible pour la chaîne qui l'attend.

Contrairement à une branche, une étiquette ne bouge pas : elle désigne un commit, définitivement. Déplacer une étiquette déjà publiée est une très mauvaise idée, pour la même raison qu'un artefact ne se réécrit pas — quelqu'un a déjà construit en s'appuyant dessus.