Comparez deux fichiers

Les « Diffs » sont la lingua franca du changement. Ce sont les récits compacts qui vous disent ce qui a bougé entre deux versions d'une chose — code source, prose, un ensemble de données — sans vous forcer à tout relire. Derrière ces quelques symboles (+, -, @@) se cache une pile profonde d'algorithmes, d'heuristiques et de formats qui équilibrent l'optimalité, la vitesse et la compréhension humaine. Cet article est une visite pratique, des algorithmes aux flux de travail, des diffs : comment ils sont calculés, comment ils sont formatés, comment les outils de fusion les utilisent et comment les régler pour de meilleures révisions. En chemin, nous appuierons nos affirmations sur des sources primaires et des documents officiels — car les moindres détails (comme le fait de savoir si les espaces comptent) ont vraiment leur importance.

Qu'est-ce qu'un « diff » en réalité

Formellement, un diff décrit un script d'édition le plus court (SES) pour transformer une séquence « ancienne » en une « nouvelle » en utilisant des insertions et des suppressions (et parfois des substitutions, qui peuvent être modélisées comme une suppression+insertion). En pratique, la plupart des diffs destinés aux programmeurs sontorientés ligne, puis éventuellement affinés en mots ou en caractères pour la lisibilité. Les sorties canoniques sont les formats contexte et unifié ; ce dernier — que vous voyez habituellement dans les revues de code — compresse la sortie avec un en-tête concis et des « hunks », chacun montrant un voisinage de contexte autour des changements. Le format unifié est sélectionné via -u/--unified et est le standard de facto pour l'application de correctifs ; patch bénéficie généralement des lignes de contexte pour appliquer les changements de manière robuste.

Le manuel de GNU diff catalogue les commutateurs que vous utilisez lorsque vous voulez moins de bruit et plus de signal — ignorer les espaces, développer les tabulations pour l'alignement, ou demander un script d'édition « minimal » même s'il est plus lent (référence des options). Ces options ne changent pas ce que cela signifie pour deux fichiers de différer ; elles changent la manière agressive dont l'algorithme recherche des scripts plus petits et comment le résultat estprésenté aux humains.

De LCS à Myers : comment les diffs sont calculés

La plupart des diffs de texte sont construits sur l'abstraction de la plus longue sous-séquence commune (LCS) . La programmation dynamique classique résout la LCS en temps et en espace O(mn), mais c'est trop lent et gourmand en mémoire pour les gros fichiers. L'algorithme de Hirschberg a montré comment calculer des alignements optimaux en espace linéaire (toujours en temps O(mn)) en utilisant la méthode diviser pour régner, une technique fondamentale d'économie d'espace qui a influencé les implémentations pratiques de diff.

Pour la vitesse et la qualité, la percée a été l'algorithme d'Eugene W. Myers de 1986, qui trouve un SES en temps O(ND) (N ≈ nombre total de lignes, D ≈ distance d'édition) et en espace quasi linéaire. Myers modélise les éditions dans un « graphe d'édition » et avance le long des frontières les plus étendues, produisant des résultats à la fois rapides et proches du minimum dans le contexte du diff de lignes. C'est pourquoi « Myers » reste la valeur par défaut dans de nombreux outils.

Il y a aussi la famille Hunt–Szymanski , qui accélère la LCS lorsque peu de positions correspondent (en pré-indexant les correspondances et en poursuivant les sous-séquences croissantes), et est historiquement liée aux premières variantes de diff. Ces algorithmes éclairent les compromis : dans les entrées avec des correspondances éparses, ils peuvent s'exécuter de manière sous-quadratique. Pour un aperçu pratique faisant le pont entre la théorie et l'implémentation, voir les notes de Neil Fraser.

Quand l'« optimal » n'est pas lisible : stratégies de patience et d'histogramme

Myers vise des scripts d'édition minimaux, mais « minimal » ≠ « le plus lisible ». De grands blocs réorganisés ou dupliqués peuvent tromper un algorithme SES pur en alignements maladroits. Entrez patience diff, attribué à Bram Cohen : il s'ancre sur des lignes uniques et de basse fréquence pour stabiliser les alignements, produisant souvent des diffs que les humains trouvent plus propres — en particulier dans le code avec des fonctions déplacées ou des blocs réorganisés. De nombreux outils exposent cela via une option « patience » (par ex.,diff.algorithm).

Histogram diff étend la patience avec un histogramme de fréquence pour mieux gérer les éléments à faible occurrence tout en restant rapide (popularisé dans JGit). Si vous avez déjà trouvé que --histogram produisait des hunks plus clairs pour les fichiers bruyants, c'est par conception. Sur Git moderne, vous pouvez choisir l'algorithme globalement ou par invocation :git config diff.algorithm myers|patience|histogram ou git diff --patience.

Clarté au niveau du mot, contrôle des espaces et mise en évidence du code déplacé

Les diffs de ligne sont concis mais peuvent masquer de petites modifications. Les diffs au niveau du mot (--word-diff) colorent les changements intra-ligne sans inonder la revue avec des insertions/suppressions de lignes entières — idéal pour la prose, les longues chaînes de caractères ou les lignes uniques.

Les espaces peuvent submerger les diffs après un reformatage. Git et GNU diff vous permettent tous deux d' ignorer les changements d'espaces à différents degrés et les options d'espaces de GNU diff (-b, -w, -B) aident lorsqu'un formateur s'exécute ; vous verrez des modifications logiques au lieu de bruit d'alignement.

Lorsque le code se déplace en bloc, Git peut mettre en évidence les blocs déplacés avec --color-moved, séparant visuellement « déplacé » de « modifié », ce qui aide les réviseurs à vérifier qu'un déplacement n'a pas caché de modifications non intentionnelles. Persistez-le via diff.colorMoved.

Les diffs au service des fusions : deux voies vs. trois voies et diff3

Un diff à deux voies compare exactement deux versions ; il ne peut pas dire si les deux côtés ont modifié la même ligne de base, donc il génère souvent trop de conflits. La fusion à trois voies (utilisée par les VCS modernes) calcule les diffs à partir d'un ancêtre communde chaque côté, puis réconcilie les deux ensembles de changements. Cela réduit considérablement les conflits parasites et fournit un meilleur contexte. Le cœur algorithmique classique ici est diff3, qui fusionne les changements de « O » (base) à « A » et « B » et marque les conflits si nécessaire.

Le travail académique et industriel continue de formaliser et d'améliorer l'exactitude de la fusion ; par exemple, les fusions à trois voies vérifiées proposent des notions sémantiques de non-conflit. Au quotidien dans Git, la stratégie de fusion moderne ort s'appuie sur le diffing et la détection de renommage pour produire des fusions avec moins de surprises. Pour les utilisateurs, les conseils clés sont : afficher les lignes de base dans les conflits avec merge.conflictStyle=diff3, et intégrer fréquemment pour que les diffs restent petits.

Détection de renommage et ses seuils

Les diffs traditionnels ne peuvent pas « voir » les renommages car l'adressage par contenu traite les fichiers comme des blobs ; ils ne voient qu'une suppression et une ajout. Les heuristiques de détection de renommage comblent cette lacune en comparant la similarité entre les paires ajoutées/supprimées. Dans Git, activez ou ajustez via -M/--find-renames[=<n>] (la valeur par défaut est d'environ 50 % de similarité). Abaissez-la pour les déplacements plus bruyants. Vous pouvez limiter les comparaisons de candidats avec diff.renameLimit (et merge.renameLimit pendant les fusions). Pour suivre l'historique à travers les renommages, utilisez git log --follow -- <path>. Git récent effectue également une détection de renommage de répertoire pour propager les déplacements de dossiers pendant les fusions.

Diffs binaires et delta : rsync, VCDIFF/xdelta, bsdiff

Le texte n'est pas la seule chose qui change. Pour les binaires, vous voulez généralement un encodage delta — émettre des instructions de copie/ajout pour reconstruire une cible à partir d'une source. L' algorithme rsync a été le pionnier de la différenciation à distance efficace en utilisant des sommes de contrôle roulantes pour aligner les blocs à travers un réseau, minimisant la bande passante.

L'IETF a normalisé un format delta générique, VCDIFF (RFC 3284), décrivant un bytecode de ADD, COPY et RUN, avec des implémentations comme xdelta3 l'utilisant pour les correctifs binaires. Pour les correctifs compacts sur les exécutables, bsdiff produit souvent de très petits deltas via des tableaux de suffixes et de la compression ; choisissez-le lorsque la taille du correctif domine et que la génération peut se faire hors ligne.

Diffs de texte au-delà du code source : correspondance floue et application de correctifs

Lorsque vous avez besoin d'une application de correctifs robuste face à des modifications concurrentes ou à des contextes légèrement désalignés — pensez aux éditeurs ou aux systèmes collaboratifs — envisagez diff-match-patch. Il marie la différenciation de style Myers avec Bitap la correspondance floue pour trouver des correspondances proches et appliquer des correctifs « au mieux », plus des accélérations avant diff et des nettoyages après diff qui échangent un tout petit peu de minimalisme contre une sortie humaine plus agréable. Pour savoir comment combiner diff et correctif flou dans des boucles de synchronisation continue, consultez la Synchronisation Différentiellede Fraser.

Diffs de données structurées : tableaux et arbres

Les diffs de ligne sur CSV/TSV sont fragiles car un changement d'une seule cellule peut ressembler à une modification de ligne entière. Les outils de diff conscients des tableaux (daff) traitent les données comme des lignes/colonnes, émettant des correctifs qui ciblent des cellules spécifiques et rendant des visualisations qui rendent les ajouts, suppressions et modifications évidents (voir la vignette R). Pour des vérifications rapides, des différenciateurs CSV spécialisés peuvent mettre en évidence les changements cellule par cellule et les changements de type ; ils ne sont pas algorithmiquement exotiques, mais ils augmentent le signal de révision en comparant la structure qui vous intéresse réellement.

Réglage pratique de Git diff : une liste de contrôle pour le réviseur

• Choisissez le bon algorithme : commencez avec Myers (par défaut), essayez --patience si les réorganisations ou les blocs bruyants embrouillent la sortie, ou --histogram pour des diffs rapides et lisibles sur du texte répétitif. Définissez une valeur par défaut avec git config diff.algorithm ….
• Réduisez le bruit : pour les modifications de style uniquement, utilisez les indicateurs d'espaces (-b, -w, --ignore-blank-lines) pour vous concentrer sur les changements de fond. En dehors de Git, voir les contrôles d'espaces de GNU diff.
• Voir à l'intérieur d'une ligne : --word-diff aide pour les longues lignes et la prose.
• Auditez le code déplacé : --color-moved (ou diff.colorMoved) sépare « déplacé » de « modifié ».
• Gérez les renommages : lors de la révision de refactorisations, ajoutez -M ou ajustez le seuil de similarité (-M90%, -M30%) pour attraper les renommages ; rappelez-vous que la valeur par défaut est d'environ 50 %. Pour les arborescences profondes, définissez diff.renameLimit.
• Suivez l'historique à travers les renommages : git log --follow -- <path>.

Comment les fusions consomment réellement les diffs (et que faire quand elles ne le font pas)

Une fusion calcule deux diffs (BASE→OURS, BASE→THEIRS) et essaie d'appliquer les deux à BASE. Des stratégies comme ort orchestrent cela à grande échelle, en intégrant la détection de renommage (y compris les déplacements à l'échelle du répertoire) et des heuristiques pour minimiser les conflits. Lorsque des conflits se produisent, --conflict=diff3 enrichit les marqueurs avec le contexte de base, ce qui est inestimable pour comprendre l'intention. Le chapitre de Pro Git sur la Fusion Avancée parcourt les modèles de résolution, et les documents de Git listent des boutons comme -X ours et -X theirs. Pour gagner du temps sur les conflits récurrents, activez rerere pour enregistrer et rejouer vos résolutions.

Au-delà des fichiers : scénarios distants et incrémentiels

Si vous synchronisez de gros actifs sur un réseau, vous êtes plus proche du rsync monde que du diff local. Rsync calcule des sommes de contrôle roulantes pour découvrir les blocs correspondants à distance, puis ne transfère que ce qui est nécessaire. Pour les deltas empaquetés, VCDIFF/xdelta vous donne un bytecode standard et des outils matures ; choisissez-le lorsque vous contrôlez à la fois l'encodeur et le décodeur. Et si la taille du correctif est primordiale (par ex., firmware en direct), bsdiff échange CPU/mémoire au moment de la construction contre de très petits correctifs.

Un mot rapide sur « flou » et « amical »

Des bibliothèques comme diff-match-patch acceptent que, dans le monde réel, le fichier que vous corrigez ait pu dériver. En combinant un diff solide (souvent Myers) avec une correspondance floue (Bitap) et des règles de nettoyage configurables, elles peuvent trouver le bon endroit pour appliquer un correctif et rendre le diff plus lisible — essentiel pour l'édition collaborative et la synchronisation.

Les « enjeux de table » que vous devriez intérioriser

1. Connaissez vos formats. Les diffs unifiés (-u/-U<n>) sont compacts et conviviaux pour les correctifs ; c'est ce que la revue de code et la CI attendent (référence).
2. Connaissez vos algorithmes. Myers pour des modifications minimales rapides (article) ; patience/histogramme pour la lisibilité sur les réorganisations ou les blocs bruyants (patience, histogramme) ; Hirschberg pour l'astuce de l'espace linéaire (article) ; Hunt–Szymanski pour l'accélération des correspondances éparses (article).
3. Connaissez vos commutateurs. Les contrôles d'espaces, word-diff et color-moved sont des multiplicateurs de révision (docs git diff; options d'espaces GNU).
4. Connaissez vos fusions. La fusion à trois voies avec diff3 -style est moins déroutante ; ort plus la détection de renommage réduit le taux de désabonnement ; rerere fait gagner du temps.
5. Choisissez le bon outil pour les données. Pour les CSV/tableaux, utilisez daff; pour les binaires, utilisez VCDIFF/xdelta ou bsdiff.

Annexe : petit livre de recettes de commandes

Parce que la mémoire musculaire compte :

# Afficher un diff unifié standard avec un contexte supplémentaire
  git diff -U5
  diff -u -U5 a b
  
  # Obtenir une clarté au niveau du mot pour les longues lignes ou la prose
  git diff --word-diff
  
  # Ignorer le bruit des espaces après le reformatage
  git diff -b -w --ignore-blank-lines
  diff -b -w -B a b
  
  # Mettre en évidence le code déplacé lors de la révision
  git diff --color-moved
  git config --global diff.colorMoved default
  
  # Maîtriser les refactorisations avec la détection de renommage et suivre l'historique à travers les renommages
  git diff -M
  git log --follow -- <file>
  
  # Préférer l'algorithme pour la lisibilité
  git diff --patience
  git diff --histogram
  git config --global diff.algorithm patience
  
  # Voir les lignes de base dans les marqueurs de conflit
  git config --global merge.conflictStyle diff3

Pensée finale

Les grands diffs visent moins à prouver la minimalité qu'à maximiser la compréhension du réviseur à un coût cognitif minimum. C'est pourquoi l' écosystème a développé plusieurs algorithmes (Myers, patience, histogramme), plusieurs présentations (unifié, word-diff, color-moved) et des outils spécifiques au domaine (daff pour les tableaux, xdelta/bsdiff pour les binaires). Apprenez les compromis, ajustez les boutons, et vous passerez plus de temps à raisonner sur l'intention et moins de temps à réassembler le contexte à partir de lignes rouges et vertes.