Le lundi matin, enfin résolu
Souvenez-vous de la leçon 1.3 : deux cents utilisateurs sans lecteur réseau, un script modifié un vendredi soir, et cinq questions sans réponse.
Vous disposez maintenant de l’outillage. Cette leçon est celle où Git cesse d’être un système de sauvegarde pour devenir un outil d’investigation.
Quatre commandes suffisent. Nous les verrons d’abord séparément, puis assemblées en une méthode d’enquête.
git log — parcourir l’histoire
Vous connaissez la forme de base depuis la leçon 1.7. Voici ce qui la rend réellement utile.
Les vues
git log --oneline # une ligne par enregistrement
git log --stat # + les fichiers touchés et le volume
git log -p # + le détail des changements
git lg # l'alias configuré en 1.6, avec le graphe
--stat mérite d’être connu : il donne un aperçu immédiat de l’ampleur d’un changement.
7d2e881 Migration du partage compta vers SRV-FIC02
Logon.ps1 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Une ligne modifiée dans un fichier. On sait tout de suite que ce n’est pas cet enregistrement qui a cassé le serveur de fichiers.
Filtrer
C’est là que ça devient intéressant.
# Sur une période
git log --since="2026-08-01" --until="2026-08-10"
git log --since="3 days ago"
# Par auteur
git log --author="Nicolas"
# Par mot-clé dans le message
git log --grep="compta"
# Les N derniers
git log -5
Ces options se combinent librement :
git log --oneline --since="vendredi" --author="Nicolas"
Que Nicolas a-t-il publié depuis vendredi ? Une commande, trois secondes.
L’historique d’un seul fichier
git log --oneline -- Logon.ps1
Le double tiret sépare les options du chemin. Il évite l’ambiguïté quand un fichier porte le même nom qu’une branche — ce qui arrive plus souvent qu’on ne croit.