Commits et historique

Pourquoi versionner, même en IT

Git n'est pas réservé aux développeurs. Un fichier de configuration Ansible, un script PowerShell, ou une documentation technique bénéficient tout autant d'un historique de versions : savoir qui a changé quoi, quand, et pourquoi, et pouvoir revenir en arrière en cas d'erreur.

Les trois zones de Git

flowchart LR
    A[Répertoire de travail\nfichiers modifiés] -->|git add| B[Zone de staging\nprêt à committer]
    B -->|git commit| C[Historique local\ncommit enregistré]
    C -->|git push| D[Dépôt distant\nGitHub/GitLab]

Le cycle add / commit / push

git status                          # voir ce qui a changé
git add fichier.yml                 # préparer un fichier pour le commit
git add .                           # préparer tous les fichiers modifiés
git commit -m "Ajoute la config VLAN 20"   # enregistrer un instantané avec message
git push                            # envoyer les commits vers le dépôt distant

Un bon message de commit

Un message de commit doit expliquer le pourquoi, pas seulement le quoi (le diff montre déjà le quoi). "Fix bug" n'aide personne 6 mois plus tard ; "Corrige le timeout SSH qui bloquait le déploiement Ansible sur les serveurs distants" oriente immédiatement.

Consulter l'historique

git log                             # historique complet des commits
git log --oneline                   # version condensée, un commit par ligne
git diff                            # voir les changements non encore commités
git show <hash-du-commit>           # détail complet d'un commit précis

Cas concret

Une configuration réseau produite via un script est modifiée par erreur, cassant le déploiement. git log --oneline révèle l'historique des 10 derniers commits, et git diff entre la version actuelle et la version d'avant la casse montre exactement quelle ligne a introduit le problème, en quelques secondes plutôt qu'en réanalysant tout le fichier manuellement.

Erreurs fréquentes

• Committer avec des messages vides ou génériques ("update", "fix") : rend l'historique inutile pour comprendre les changements passés.
• Oublier git add avant git commit : Git ne commite que ce qui a été explicitement ajouté à la zone de staging, pas automatiquement tous les fichiers modifiés.
• Ne jamais consulter git log avant de chercher la cause d'un bug récent, alors que l'historique révèle souvent immédiatement quel changement l'a introduit.

À retenir

• Git suit trois zones : répertoire de travail, staging (add), historique local (commit), avant envoi distant (push).
• Un bon message de commit explique le pourquoi du changement, pas seulement ce qui a changé.
• git log et git diff permettent de retrouver rapidement quand et pourquoi un changement a été introduit.

Mini-exercice

Un fichier de configuration casse un déploiement après plusieurs modifications au fil des semaines. Quelle commande Git permet de localiser rapidement quel commit a introduit le problème ?

Réponse : git log --oneline pour parcourir l'historique, puis git diff entre deux commits successifs pour identifier précisément la ligne modifiée qui a cassé le déploiement, sans devoir tout relire manuellement.