Vous avez hérité d’un projet et vous vous demandez par où l’attraper ? Moi, c’est toujours par le même bout : la gestion de version. Pas de Git du tout, un dossier zippé reçu par email, ou un historique de 2000 commits tous intitulés « fix ». Voilà l’état dans lequel ces projets me parviennent côté versionnement, et c’est là-dessus que je pose ma première pierre.
Ma priorité sur un projet hérité reste la même à chaque fois : figer un état de référence propre dans un dépôt Git, en sortir ce qui n’a rien à y faire (secrets, dépendances, fichiers générés), et poser deux ou trois règles simples pour la suite.
Pourquoi ce point d’abord, et rien d’autre
Sans contrôle de version propre, vous travaillez sans filet. Impossible de savoir ce qui a changé hier, de revenir en arrière sans casser le reste, de collaborer autrement qu’au bricolage. Mettre le projet sous Git, c’est se donner un point fixe : l’état initial figé, puis chaque geste tracé.
Une fois, j’ai repris un site de PME où le « versionnement » tenait dans trois dossiers, site, site-old et site-old-vraiment. Personne ne savait lequel tournait en production. Trancher ça m’a pris une matinée, avant même d’écrire la moindre ligne. C’est typique : ce qui coûte du temps, ce n’est jamais le code, c’est de retrouver ce qui sert vraiment.
Ce que je mets dedans, et ce que j’en sors
Je place le code dans un dépôt propre et je fige l’existant tel quel. S’il existe un historique exploitable, je le garde. Sinon je repars d’une base nette, sans reconstituer un passé qui n’existe plus. Le but n’est pas un historique parfait mais une fondation fiable.
Un dépôt sain ne contient que les sources. Via le fichier d’exclusion (le .gitignore), j’écarte dès le départ trois familles de fichiers :
- Les secrets : mots de passe, clés, jetons. Un secret qui passe dans un commit fuit pour de bon, parce que Git en garde la trace même après suppression. La priorité, c’est de le changer, pas seulement de le retirer du prochain commit.
- Les dépendances installables : le
node_modulesou levendorse récupèrent en une commande. Les versionner ne fait que gonfler le dépôt inutilement. - Les fichiers générés : compilations, caches, sorties de build se reconstruisent à la demande.
Cette hygiène vous épargne deux ennuis : un dépôt qui enfle sans raison, et des secrets qui partent en clair dans un historique que vous ne maîtrisez plus une fois le dépôt poussé.
Le geste concret pour démarrer demain matin
Si vous deviez ne faire qu’une chose cette semaine : avant le premier git add, ouvrez votre .gitignore et listez à la main les fichiers de configuration qui contiennent une URL de base de données, un mot de passe ou une clé d’API. Cherchez-les un par un, ne faites pas confiance à un modèle générique récupéré en ligne. C’est ce passage en revue, fait à froid, qui évite la fuite la plus courante et la plus pénible à rattraper. Le reste de la discipline (commits cohérents, une branche par modification sérieuse, une production déployée depuis une référence connue) se met en place ensuite, sans précipitation.