1. Préparation des fichiers de test

Pour illustrer le fonctionnement de git diff, deux fichiers Java simples sont nécessaires.

Fichier A : Analyseur.java (dans le dossier version_un)

import java.util.Arrays;

public class Analyseur {
    public static void main(String[] args) {
        int[] donnees = {5, 12, 8, 20, 3};
        int seuil = 10;
        long compteur = compterSuperieurSeuil(donnees, seuil);
        System.out.println("Nombre d'éléments au-dessus du seuil : " + compteur);
    }

    private static long compterSuperieurSeuil(int[] tableau, int valeurSeuil) {
        return Arrays.stream(tableau).filter(element -> element > valeurSeuil).count();
    }
}

Fichier B : Traitement.java (dans le dossier version_deux)

import java.util.Arrays;

public class Traitement {
    private static final int BORNE = 15;

    public static void main(String[] args) {
        int[] donnees = {5, 12, 8, 20, 3};
        int seuil = 10;
        long compteur = compterSuperieurSeuil(donnees, seuil);
        // Ligne de log retirée pour l'exemple
        System.out.println("Résultat final : " + compteur);
    }

    private static long compterSuperieurSeuil(int[] tableau, int valeurSeuil) {
        return Arrays.stream(tableau).filter(element -> element > valeurSeuil).count();
    }
}

2. Exécution de la commande de comparaison

La commande fondamentale pour comparer deux fichiers non ancore indexés est :

git diff --no-index version_un/Analyseur.java version_deux/Traitement.java

L'exécution produit un résultat structuré similaire à celui-ci :

diff --git a/version_un/Analyseur.java b/version_deux/Traitement.java
index a1b2c3d..e4f5g6h 100644
--- a/version_un/Analyseur.java
+++ b/version_deux/Traitement.java
@@ -1,12 +1,13 @@
-package version_un;
+package version_deux;
 
 import java.util.Arrays;
 
-public class Analyseur {
+public class Traitement {
+    private static final int BORNE = 15;
+
     public static void main(String[] args) {
         int[] donnees = {5, 12, 8, 20, 3};
         int seuil = 10;
         long compteur = compterSuperieurSeuil(donnees, seuil);
-        System.out.println("Nombre d'éléments au-dessus du seuil : " + compteur);
+        // Ligne de log retirée pour l'exemple
+        System.out.println("Résultat final : " + compteur);
     }
 

3. Analyse du format de sortie

Chaque section du résultat contient des métadonnées cruciales.

• Ligne d'en-tête : diff --git a/... b/.... Elle indique les deux points de la comparaison, le premier (a/) étant la référence initiale et le second (b/) l'état modifié.
• Ligne d'index : index a1b2c3d..e4f5g6h 100644. Les valeurs hexadécimales (a1b2c3d, e4f5g6h) sont les identifiants uniques des versions (blobs) dans le dépôt Git. Le mode 100644 désigne un fichier ordinaire.
• Marqueurs de version : --- a/... représente la version d'origine (à supprimer). +++ b/... représente la nouvelle version (à ajouter).
• Plage de modification (hunk) : @@ -1,12 +1,13 @@. Cette ligne délimite la zone de changement. -1,12 signifie "à partir de la ligne 1 du fichier original, concernant 12 lignes". +1,13 signifie "à partir de la ligne 1 du nouveau fichier, concernant 13 lignes".
• Contenu des modifications :
  • + private static final int BORNE = 15; : Une ligne entièrement ajoutée.
  • - System.out.println("Nombre d'éléments ...") et + // Ligne de log retirée... : Une ligne remplacée. L'outil ne possède pas de concept natif de "modification" ; c'est toujours une suppression suivie d'une addition.

4. Applications pratiques de l'analyse des différences

L'analyse programmatique de la sortie de git diff ouvre la porte à des automatisations précieuses dans le cycle de développement. Par exemple, dans un pipeline d'intégration continue (CI), un script peut extraire la liste des fichiers et des lignes modifiées. Cette information peut être croisée avec les données de couverture de code des tests unitaires pour générer un rapport de risque. Les modifications dans une zone non couverte par des tests sont signalées comme potentiellement critiques, permettant aux équipes de concentrer leurs efforts de test de manière plus stratégique. Cela aide à garantir que les changements de code sont non seulement fonctionnels, mais également robustes et maintenables.