La timeline de fichier : regardez n'importe quel fichier évoluer commit par commit

La question que tout développeur finit par se poser

Ça fonctionnait le mois dernier. Vous en êtes sûr. La sidebar était alignée, le parseur de dates gérait les fuseaux horaires, le bouton avait la bonne nuance de bleu. Puis un rapport de bug arrive, et vous voilà face à un fichier avec deux ans d'historique, à tenter de répondre à une question faussement simple : quand est-ce que cela a changé, et quel commit est responsable ?

Juste derrière vient la deuxième question : qui a fait cette modification, et pourquoi ? Le message du commit l'explique peut-être. L'auteur s'en souvient peut-être. Mais il faut d'abord trouver le commit, et c'est là que la gymnastique mentale commence.

La boîte à outils CLI, et ses limites

Git possède déjà tout ce qu'il faut pour enquêter sur l'historique d'un fichier. Les outils sont puissants et éprouvés -- la friction ne vient pas d'une commande en particulier, mais du nombre de commandes qu'il faut enchaîner.

git log --follow

git log --follow --oneline -- src/styles/sidebar.css

Cette commande liste chaque commit qui a touché le fichier, même à travers les renommages. C'est le bon point de départ. Mais elle vous donne des SHA et des messages de commit, pas du contenu. Pour voir à quoi ressemblait réellement le fichier à un moment donné, il vous faut la commande suivante.

git show SHA:path

git show a3b4c5d:src/styles/sidebar.css

Cette commande affiche le fichier complet tel qu'il existait à ce commit. Pour comparer deux versions, lancez-la deux fois et faites un diff de la sortie, ou utilisez git diff a3b4c5d 9f2e1d0 -- src/styles/sidebar.css. Maintenant, répétez cela pour chaque commit candidat. Si trente commits ont touché le fichier, vous allez copier-coller des SHA pendant un moment, tout en gardant en tête les différences entre les versions du début à la fin.

git blame

git blame src/styles/sidebar.css

Blame annote chaque ligne avec le dernier commit qui l'a modifiée. C'est excellent quand la ligne suspecte est toujours dans le fichier et que vous voulez savoir qui l'a écrite. C'est moins utile quand la régression vient d'une ligne qui a été supprimée, ou quand la modification la plus récente d'une ligne est un reformatage anodin qui masque le changement qui vous intéresse vraiment. Vous vous retrouvez alors à lancer git blame SHA^ -- path encore et encore, en remontant l'historique couche par couche.

git bisect

Bisect effectue une recherche dichotomique sur l'ensemble de votre historique pour trouver le commit qui a cassé un comportement testable. Quand « cassé » signifie que le build échoue ou qu'un test passe au rouge, bisect est exactement le bon outil, et rien dans une interface graphique ne le remplace. Mais c'est de l'artillerie lourde pour une question comme « quand cette règle CSS a-t-elle changé ? ». Vous n'avez pas besoin de faire un checkout et de reconstruire le projet à chaque étape -- vous voulez juste regarder un fichier au fil du temps.

La réponse de la CLI à « regarder ce fichier évoluer » est donc : lister les commits avec log, afficher chaque version avec show, comparer les paires à la main, et garder tout l'état dans votre tête. Chaque commande fonctionne. C'est le workflow qui pose problème.

La timeline de fichier : une réponse visuelle

GitSquid a livré la timeline de fichier dans la v2.6, et elle est incluse dans l'offre gratuite. L'idée est simple : au lieu de reconstruire l'évolution d'un fichier commit par commit dans votre tête, vous la regardez se dérouler à l'écran.

Ouvrez-la d'un clic droit

Faites un clic droit sur n'importe quel fichier et choisissez Afficher l'historique. La vue d'historique du fichier s'ouvre, entièrement centrée sur ce seul fichier.

Un repère par commit

Une bande de timeline se trouve au-dessus du visualiseur de fichier : un repère pour chaque commit qui a touché le fichier. Toute la vie du fichier, déroulée horizontalement. Un fichier avec trois commits paraît tranquille ; un fichier avec soixante repères vous en dit long sur son agitation avant même que vous ayez lu une seule ligne.

Naviguez entre les versions

Faites glisser le curseur et le visualiseur se met à jour pendant le glissement. C'est le cœur de la fonctionnalité : vous ne sautez pas entre des instantanés discrets que vous devez comparer mentalement -- vous regardez le fichier changer. Les allers-retours semblent instantanés après le premier passage, donc une fois que vous avez traversé l'historique une fois, vous pouvez osciller librement autour d'une zone suspecte et cerner le commit exact où les choses ont changé.

Survolez pour voir qui a changé quoi

Survolez n'importe quel repère et vous obtenez l'auteur et les informations du commit pour ce point de l'historique. La question « qui a écrit ça et quand » trouve sa réponse sans quitter la timeline, et sans lancer blame du tout.

Appuyez sur lecture

Cliquez sur ▶ et GitSquid parcourt automatiquement l'historique. Pour une première passe sur un fichier inconnu, c'est le moyen le plus rapide de se forger une intuition : vous voyez les structures apparaître, grandir, être refactorisées. C'est la différence entre lire trente diffs et regarder un time-lapse.

Snapshot ou Diff

Un sélecteur Snapshot / Diff dans l'en-tête bascule entre deux vues : le contenu complet du fichier tel qu'il existait à ce commit, ou le diff classique fichier contre parent. Le mode Snapshot répond à « à quoi ressemblait le fichier à l'époque ? » ; le mode Diff répond à « qu'est-ce que ce commit a changé exactement ? ». La chasse aux régressions commence généralement en mode Snapshot et se termine en mode Diff.

Sautez vers une version

Une fois que vous avez trouvé la version qui vous intéresse, trois actions sur la droite vous emmènent plus loin : Copier le SHA place le hash du commit dans votre presse-papiers pour l'utiliser n'importe où, Ouvrir le commit vous amène au commit complet pour voir ce qui a changé d'autre en même temps que votre fichier, et Checkout détaché place votre répertoire de travail exactement à ce commit quand vous avez besoin d'exécuter l'ancien code pour de vrai.

Pas à pas : trouver une régression CSS

Un exemple concret. La sidebar de votre application a perdu son padding, et personne ne sait quand. Voici la traque avec la timeline de fichier :

1. Clic droit sur sidebar.css → Afficher l'historique. La timeline affiche 24 repères répartis sur huit mois.
2. Parcourez du plus récent au plus ancien en surveillant la règle de padding. Vers les deux tiers, la règle change visiblement. Après le premier passage, la navigation est instantanée, alors vous faites osciller le curseur autour de cette zone jusqu'à isoler le repère exact où la valeur a basculé.
3. Survolez le repère. C'était un collègue, il y a trois semaines, dans un commit étiqueté comme un refactoring de layout. Mystère à moitié résolu.
4. Passez en Diff. Le sélecteur affiche le diff fichier contre parent : le padding a été condensé en une propriété raccourcie, et une valeur s'est perdue en route. Voilà la régression.
5. Ouvrir le commit. Le commit complet révèle qu'il a touché douze fichiers dans le cadre d'un grand nettoyage -- le genre de changement facile à sous-relire. Si votre équipe débat de la manière dont de tels changements devraient atterrir dans l'historique, consultez rebase vs merge.
6. Copiez le SHA et corrigez. Une fois le commit fautif identifié, vous pouvez le revert, corriger en avançant, ou faire un cherry-pick pour le contourner -- notre guide sur comment annuler un commit Git détaille quelle option convient à quelle situation.

Temps total : quelques minutes, aucun SHA mémorisé, aucune archéologie dans l'historique du terminal.

Quand blame ou bisect reste le bon outil

La timeline ne remplace pas le reste de la boîte à outils, et prétendre le contraire serait malhonnête :

• Utilisez blame quand vous regardez déjà une ligne précise et que vous voulez connaître son dernier auteur sur place. Pour une seule ligne qui n'a pas été reformatée récemment, blame reste le chemin le plus court.
• Utilisez bisect quand le symptôme est « le build est cassé » ou « un test échoue » et que vous ne savez pas quel fichier est responsable. Bisect explore l'historique de tout le dépôt ; la timeline examine un seul fichier. Ils répondent à des questions différentes.
• Utilisez la timeline quand la question porte sur l'évolution d'un fichier : quand cela a-t-il changé, qui l'a changé, et à quoi cela ressemblait avant.

Regardez votre propre code évoluer

La timeline de fichier est incluse dans l'offre gratuite de GitSquid -- pas de compte, pas de télémétrie, natif sur macOS, Windows et Linux. Ouvrez un dépôt, faites un clic droit sur un fichier qui vous a toujours intrigué, et appuyez sur lecture.

Téléchargez GitSquid Free et offrez à votre prochaine chasse à la régression une timeline plutôt qu'une liste de SHA.