Là où Git sert le plus en informatique de gestion
Peu d'administrateurs écrivent des applications. Beaucoup gèrent des fichiers dont une modification malheureuse arrête un service : configurations de serveur, scripts d'exploitation, définitions d'infrastructure, procédures.
Ces fichiers ont exactement le besoin auquel Git répond : savoir qui a changé quoi, quand, pourquoi, et revenir en arrière en une commande.
Ce qui gagne à être versionné
Les scripts d'exploitation. Le script de sauvegarde modifié un vendredi soir et qui ne tourne plus le lundi est un classique. L'historique donne la réponse en trente secondes.
Les fichiers de configuration. Serveur web, pare-feu, supervision. La question « qu'est-ce qui a changé depuis que ça marchait » ne se pose qu'une fois quand les fichiers sont versionnés.
Les définitions d'infrastructure. Un descripteur de conteneur ou un manifeste décrit un état ; sans historique, la dérive entre le fichier et la réalité devient invisible.
Les procédures et la documentation. Le format texte, en Markdown, est ce qui rend l'historique lisible. Un document bureautique versionné dans Git ne montre aucun diff exploitable, et il perd donc l'essentiel du bénéfice.
Ce qui ne gagne rien, ou perd
Les fichiers binaires volumineux : archives, images de machines, exports de base. Git conserve chaque version intégralement, et le dépôt devient inutilisable en quelques mois.
Les données de production. Un dépôt n'est ni une sauvegarde ni une base.
Tout ce qui contient un secret. Sans exception, et sans « juste le temps du test ».
Le fichier d'exclusion, écrit avant le premier commit
*.key
*.pem
.env
config.local.yml
*.sql
*.zip
L'ordre compte : un fichier déjà commité n'est plus protégé par une exclusion ajoutée après coup. L'exclusion empêche d'ajouter, elle ne retire pas ce qui est déjà là.
La méthode qui fonctionne : versionner un modèle sans valeurs, du type config.exemple.yml, et exclure le fichier réel. Chacun copie le modèle et remplit ses valeurs localement.
Un cas concret
Une équipe versionne les fichiers de configuration de son pare-feu. Un jeudi, un flux applicatif cesse de passer sans qu'aucune intervention n'ait été annoncée.
git log --oneline -- pare-feu/regles.conf
git diff HEAD~1 HEAD -- pare-feu/regles.conf
Deux commandes, et la règle supprimée par erreur apparaît, avec son auteur, sa date et le message expliquant l'intention. Le retour en arrière prend une commande de plus.
Sans versionnement, la même recherche se fait par interrogatoire et par mémoire, avec un résultat incertain.
À retenir
Versionnez ce qui est du texte et dont une modification casse un service. Excluez le binaire volumineux, les données et les secrets, et écrivez le fichier d'exclusion avant le premier commit, parce qu'il ne rattrape pas ce qui est déjà entré.