git log --diff-filter=A --name-only -- 'assets/dist/*' | wc -l : sur un thème maintenu depuis trois ans par plusieurs développeurs successifs, cette commande a renvoyé plus de six cents entrées. Six cents versions différentes d’un même dossier de fichiers CSS et JavaScript compilés, committées une à une à chaque modification, alors qu’aucune de ces versions intermédiaires n’avait la moindre valeur une fois la suivante poussée.
Ce cas ne porte pas sur le choix d’un outil d’intégration continue en particulier, mais sur une question plus fondamentale, souvent réglée trop tard : où doivent vivre les fichiers compilés d’un thème, et à quel moment doivent-ils être générés.
Le symptôme : un dépôt qui grossit sans rapport avec le code source
Le thème en question utilisait un pipeline de build classique (Sass compilé en CSS, modules JavaScript regroupés en un seul fichier via un bundler), avec le résultat de cette compilation committé directement dans le dépôt, aux côtés du code source qui l’avait généré. Chaque modification, même mineure, d’une seule règle CSS, entraînait la recompilation de l’ensemble et le commit du dossier dist complet, fichiers non modifiés inclus.
Au bout de trois ans, le clone complet du dépôt dépassait quarante mégaoctets rien que pour l’historique de ce dossier compilé, un poids sans rapport avec la taille réelle du code source du thème, qui tenait largement en dessous d’un mégaoctet.
Premier réflexe : sortir le dossier compilé du dépôt source
La correction commence par exclure le dossier de sortie du suivi Git, via .gitignore, et par supprimer son historique du dépôt avec un outil de réécriture comme git filter-repo, opération à mener avec précaution et en informant toute l’équipe avant de forcer la mise à jour des clones existants.
# .gitignore
assets/dist/
node_modules/
Reconstruire les assets à chaque déploiement, pas à chaque commit
Une fois le dossier compilé sorti du dépôt, il doit être régénéré automatiquement à chaque déploiement, jamais par une commande lancée manuellement sur le poste d’un développeur juste avant de pousser son code. Une étape de build, exécutée dans le pipeline de déploiement choisi par l’équipe, prend le relais :
construire-assets:
stage: build
script:
- npm ci
- npm run build
artifacts:
paths:
- assets/dist/
Cette étape produit un dossier dist à jour, propre à ce déploiement précis, sans jamais transiter par l’historique Git. Le serveur de production reçoit le résultat du build, pas les sources qui ont permis de le produire.
Étiqueter chaque mise en production avec un tag Git
Sans dossier compilé versionné, il devient impossible de retrouver « le CSS tel qu’il était en production le 12 mars » en consultant seulement l’historique du dépôt. Un tag Git, posé automatiquement à chaque déploiement réussi, comble ce manque sans réintroduire le problème initial :
- Le tag référence le commit source exact, pas le résultat compilé.
- Un rollback consiste à redéployer depuis un tag antérieur, en relançant l’étape de build sur ce point précis de l’historique.
- Le nom du tag inclut la date et un numéro de build, pour un tri chronologique immédiat dans l’interface Git.
Le cas des correctifs urgents en production
Un correctif urgent, poussé directement sur la branche de production sans repasser par le processus habituel, doit lui aussi déclencher l’étape de build avant sa mise en ligne : céder à la tentation de modifier le fichier compilé à la main sur le serveur, « juste cette fois », revient exactement à la pratique qu’on cherche à éliminer, en pire, puisque cette modification n’existe alors nulle part dans le code source.
Ce que ce nettoyage a changé au quotidien
Après la réécriture de l’historique et la mise en place de l’étape de build automatisée, la taille du dépôt cloné par un nouveau développeur a été divisée par plus de dix. Les revues de code se sont également simplifiées : une modification de trois lignes de Sass n’apparaît plus noyée au milieu de deux mille lignes de CSS minifié régénéré à l’identique dans la même proposition de fusion.
Un fichier qu’une machine peut reconstruire à l’identique à partir du code source n’a rien à faire dans l’historique de ce code source : c’est un résultat, pas une donnée à conserver.
En résumé
Committer des assets compilés dans un dépôt Git semble anodin au départ, mais l’habitude finit toujours par alourdir l’historique sans apporter de valeur réelle. Exclure ce dossier du suivi de version, reconstruire les fichiers à chaque déploiement via une étape de build dédiée, et marquer chaque mise en production d’un tag Git couvrent l’essentiel du besoin, sans jamais mélanger code source et résultat de compilation.
