.git-blame-ignore-revs est une fonctionnalité Git introduite dans la version 2.23 qui vous permet d'ignorer des validations spécifiques dans les résultats de git blâme. Ceci est particulièrement utile pour les validations groupées qui modifient un grand nombre de lignes sans altérer la fonctionnalité réelle du code, comme les modifications de formatage, le renommage ou l'application de normes de codage dans une base de code. En ignorant ces changements non fonctionnels, git blâme peut se concentrer sur des modifications significatives qui expliquent le contexte et le raisonnement derrière le code.

Pourquoi .git-blame-ignore-revs est important

Lorsque vous utilisez git blâme sur un fichier, il vous montre quel commit a modifié en dernier lieu chaque ligne du fichier, ainsi que l'auteur et l'horodatage. Ceci est utile pour déterminer pourquoi une ligne particulière a été modifiée. Cependant, si un commit important qui apporte des modifications purement de formatage, comme l'application d'une version plus jolie, fait partie de l'historique, git blâme peut pointer vers ce commit sur de nombreuses lignes. Cela rend difficile la recherche de l'historique réel des modifications fonctionnelles.

Par exemple, si votre équipe utilise un outil comme Prettier ou ESLint pour reformater l'intégralité de la base de code, la validation résultante peut toucher des milliers de lignes de code. Sans .git-blame-ignore-revs, git blâme montrerait ce commit comme responsable de chaque ligne affectée, ce qui pourrait obscurcir l'historique le plus significatif derrière chaque ligne.

En utilisant .git-blame-ignore-revs, vous pouvez dire à git blâme d'ignorer ces commits et de se concentrer sur les changements qui comptent.

Comment utiliser .git-blame-ignore-revs

Pour comprendre comment utiliser cette fonctionnalité, passons en revue un exemple du référentiel React.

Étape 1 : Identifiez les validations de formatage groupé

Le code source de React inclut des validations groupées où des outils comme Prettier ont été exécutés sur l'ensemble du projet. Voici deux de ces commits :

1. Commit : c998bb1 Message : [compilateur] Exécutez plus joliment, corrigez Snap Ce commit applique un formatage plus joli à travers la base de code, modifiant de nombreuses lignes sans changer la fonctionnalité.

2. Valider : fd2b3e1

Message : Compilateur : Débranchez une configuration plus jolie

Ce commit contient d'autres mises à jour de la configuration Prettier, affectant tous les fichiers .ts et .tsx du référentiel.

Ces commits ne traitent que du formatage et ne fournissent pas de contexte significatif lorsqu'il s'agit de rechercher pourquoi une ligne de code a été écrite telle quelle.

Étape 2 : Créez le fichier .git-blame-ignore-revs

Pour que git blâme ignore ces validations de formatage groupé, nous pouvons créer un fichier .git-blame-ignore-revs à la racine du référentiel.

1. Créez le fichier .git-blame-ignore-revs :

touch .git-blame-ignore-revs

2. Ajoutez les hachages de validation pertinents au fichier, en expliquant pourquoi chaque validation est ignorée. Dans ce cas, nous ajouterons les deux commits que nous avons identifiés précédemment :

# Prettier formatting changes 
c998bb1ed4b3285398c9c7797135d3f060243c6a 
fd2b3e13d330a4559f5aa21462e1cb2cbbcf144b

3. Enregistrez le fichier .git-blame-ignore-revs dans le référentiel. Ce fichier peut être versionné avec votre code, permettant à toute l'équipe d'utiliser la même liste de commits ignorés.

Étape 3 : Configurer Git pour utiliser .git-blame-ignore-revs

Pour éviter de saisir l'option --ignore-revs-file à chaque fois que vous utilisez git blâme, vous pouvez configurer Git pour qu'il utilise automatiquement le fichier .git-blame-ignore-revs.

1. Configurer la configuration au niveau du référentiel :

git config blame.ignoreRevsFile .git-blame-ignore-revs

Cela garantit que chaque fois que quelqu'un exécute git Blame dans ce référentiel, Git ignorera automatiquement les commits répertoriés dans .git-blame-ignore-revs.

Étape 4 : Exécutez git blâme avec les validations ignorées

Voyons comment cela fonctionne dans la pratique. Sans ignorer les validations de formatage groupé, git blâme pourrait afficher :

$ git blame src/someFile.tsx
c998bb1e (Joe Bloggs 2023-03-15 10:00:00  0200 1) import React from 'react';
fd2b3e13 (Alan 2023-04-01 14:15:30  0200 2) function App() {
c998bb1e (Joe Bloggs 2023-03-15 10:00:00  0200 3)     return 
Hello, world!
;
fd2b3e13 (Ben 2023-04-01 14:15:30  0200 4) }

Cette sortie indique que la dernière modification apportée aux lignes 1 et 3 était due à la validation de formatage Prettier (c998bb1e) et que les lignes 2 et 4 ont été modifiées dans une autre validation groupée (fd2b3e13). Puisqu’il s’agit de changements de format, cela n’est pas utile pour comprendre qui a introduit la véritable logique derrière ces lignes.

Après avoir configuré .git-blame-ignore-revs, exécuter git blâme ignorera les validations groupées et affichera le véritable historique :

$ git blame src/someFile.tsx
a23d9b34 (May 2022-12-01 09:30:00  0200 1) import React from 'react';
b12e45a6 (JJ 2022-12-05 11:45:15  0200 2) function App() {
a23d9b34 (Joe 2022-12-01 09:30:00  0200 3)     return 
Hello, world!
;
b12e45a6 (Ram 2022-12-05 11:45:15  0200 4) }

Maintenant, git blâme attribue les lignes aux commits corrects, en ignorant les modifications de formatage sans importance. Cela nous donne des informations utiles, montrant qui a effectué les modifications fonctionnelles réelles.

Conclusion

La fonctionnalité .git-blame-ignore-revs de Git 2.23 change la donne pour les projets avec un formatage groupé ou des changements de style. En créant un fichier .git-blame-ignore-revs et en configurant votre référentiel, vous pouvez appliquer des normes de codage, exécuter des outils comme Prettier ou refactoriser le code sans vous soucier de polluer l'historique des reproches.

Avec cette approche, votre équipe peut améliorer en toute confiance la qualité et le formatage du code sans sacrifier la capacité de suivre les modifications significatives, garantissant ainsi que git blâme reste un outil précieux pour comprendre l'historique et le raisonnement derrière chaque ligne de code.

À propos de nous:

Chez Think Throo, nous avons pour mission d'enseigner les concepts architecturaux avancés de base de code utilisés dans les projets open source.

10x vos compétences en codage en pratiquant des concepts architecturaux avancés dans Next.js/React, apprenez les meilleures pratiques et créez des projets de niveau production.

Nous sommes open source — https://github.com/thinkthroo/thinkthroo (Donnez-nous une étoile !)

Développez les compétences de votre équipe avec nos cours avancés basés sur l'architecture de base de code. Contactez-nous à [email protected] pour en savoir plus !

Références :

1. https://github.com/facebook/react/blob/main/.git-blame-ignore-revs

2. https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa98b9e279175f2

3. https://github.com/facebook/react/commit/c998bb1ed4b3285398c9c7797135d3f060243c6a

4. https://moxio.com/blog/ignoring-bulk-change-commits-with-git-blame/