Une introduction aux diffs et aux patchs

Si vous avez déjà travaillé sur une grande base de code avec un modèle de développement distribué, vous avez probablement entendu des gens dire des choses comme "Sue vient d'envoyer un patch" ou "Rajiv vérifie le diff". Ces termes étaient peut-être nouveaux pour vous et vous vous êtes demandé ce qu'ils signifiaient. L'open source a eu un impact ici, car le principal modèle de développement des grands projets allant du serveur Web Apache au noyau Linux a été des projets de développement «basés sur des correctifs» tout au long de leur vie. En fait, saviez-vous que le nom d'Apache provient de l'ensemble de correctifs qui ont été collectés et comparés au code source du serveur HTTPd NCSA d'origine ?

Vous pourriez penser que c'est du folklore, mais une première capture du site Web d'Apache prétend que le nom est dérivé de cette collection originale de "patchs" ; donc APA tCH y serveur, qui a ensuite été simplifié en Apache.

Mais assez d'anecdotes sur l'histoire. Que sont exactement ces correctifs et diffs dont parlent les développeurs ?

Premièrement, pour les besoins de cet article, supposons que ces deux termes font référence à une seule et même chose. "Diff" est simplement l'abréviation de "différence" ; un utilitaire Unix du même nom révèle la différence entre un ou plusieurs fichiers. Nous examinerons un exemple d'utilitaire diff ci-dessous.

Un "correctif" fait référence à une collection spécifique de différences entre les fichiers qui peuvent être appliquées à une arborescence de code source à l'aide de l'utilitaire Unix diff. Nous pouvons donc créer des diffs (ou correctifs) à l'aide de l'outil diff et les appliquer à une version non corrigée de ce même code source à l'aide de l'outil patch. En aparté (et enfreignant ma règle de ne plus avoir de futilités historiques), le mot "patch" vient de la couverture physique des trous des cartes perforées pour apporter des modifications logicielles aux débuts de l'informatique, lorsque les cartes perforées représentaient le programme exécuté par le processeur de l'ordinateur. L'image ci-dessous, trouvée sur cette page Wikipédia décrivant les correctifs logiciels, montre ce concept original de "correction" :

Maintenant que vous avez une compréhension de base des correctifs et des différences, explorons comment les développeurs de logiciels utilisent ces outils. Si vous n'avez pas utilisé un système de contrôle de code source comme Git ou Subversion, je vais préparer le terrain pour la façon dont la plupart des projets logiciels non triviaux sont développés. Si vous considérez la vie d'un projet logiciel comme un ensemble d'actions le long d'une chronologie, vous pouvez visualiser les modifications apportées au logiciel, telles que l'ajout d'une fonctionnalité ou d'une fonction à un fichier de code source ou la correction d'un bogue, apparaissant à différents moments sur la chronologie, chaque point discret représentant l'état de tous les fichiers de code source à ce moment-là. Nous appellerons ces points de changement "commits", en utilisant la même nomenclature que l'outil de contrôle de code source le plus populaire d'aujourd'hui, Git, utilise. Lorsque vous voulez voir la différence entre le code source avant et après un certain commit, ou entre plusieurs commits, vous pouvez utiliser un outil pour nous montrer les diffs ou les différences.

Si vous développez des logiciels à l'aide de ce même outil de contrôle de code source, Git, vous pouvez avoir des modifications dans votre système local que vous souhaitez fournir à d'autres pour éventuellement les ajouter en tant que commits à leur propre arborescence. Une façon de fournir des modifications locales aux autres est de créer un diff des modifications de votre arborescence locale et d'envoyer ce "correctif" à d'autres qui travaillent sur le même code source. Cela permet aux autres de patcher leur arborescence et de voir l'arborescence du code source avec vos modifications appliquées.

Linux, Git et GitHub

Ce modèle de partage de fichiers de correctifs est la façon dont la communauté du noyau Linux fonctionne en ce qui concerne les modifications proposées aujourd'hui. Si vous regardez les archives de l'une des listes de diffusion populaires du noyau Linux - LKML est la principale, mais d'autres incluent linux-containers, fs-devel, Netdev, pour n'en nommer que quelques-uns - vous trouverez de nombreux développeurs publiant des correctifs qu'ils souhaite que d'autres examinent, testent et éventuellement intègrent l'arborescence Git officielle du noyau Linux à un moment donné. Il n'entre pas dans le cadre de cet article de discuter plus en détail de Git, le système de contrôle de code source écrit par Linus Torvalds, mais il convient de noter que Git permet ce modèle de développement distribué, permettant aux correctifs de vivre séparément d'un référentiel principal, poussant et tirer dans différents arbres et suivre leur flux de développement spécifique.

Avant de poursuivre, nous ne pouvons pas ignorer le service le plus populaire dans lequel les correctifs et les diffs sont pertinents :GitHub. Étant donné son nom, vous pouvez probablement deviner que GitHub est basé sur Git, mais il offre un flux de travail basé sur le Web et l'API autour de l'outil Git pour le développement de projets open source distribués. L'une des principales façons dont les correctifs sont partagés dans GitHub n'est pas par e-mail, comme le noyau Linux, mais en créant une demande d'extraction . Lorsque vous validez des modifications sur votre propre copie d'une arborescence de code source, vous pouvez partager ces modifications en créant une demande d'extraction sur un référentiel partagé pour ce projet logiciel. GitHub est aujourd'hui utilisé par de nombreux projets open source actifs et populaires, tels que Kubernetes, Docker, l'interface réseau de conteneurs (CNI), Istio et bien d'autres. Dans le monde GitHub, les utilisateurs ont tendance à utiliser l'interface Web pour examiner les différences ou les correctifs qui composent une demande d'extraction, mais vous pouvez toujours accéder aux fichiers de correctif bruts et les utiliser en ligne de commande avec l'utilitaire de correctif.

Se mettre au travail

Maintenant que nous avons couvert les correctifs et les diffs et comment ils sont utilisés dans les communautés ou les outils open source populaires, examinons quelques exemples.

Le premier exemple comprend deux copies d'une arborescence source, et l'une contient des modifications que nous souhaitons visualiser à l'aide de l'utilitaire diff. Dans nos exemples, nous examinerons les diffs "unifiés" car c'est la vue attendue pour les correctifs dans la plupart des développements logiciels modernes. Consultez la page de manuel diff pour plus d'informations sur les options et les moyens de produire des différences. Le code source d'origine se trouve dans sources-orig et notre seconde base de code modifiée se trouve dans un répertoire nommé sources-fixed. Pour afficher les différences dans un format diff unifié dans votre terminal, utilisez la commande suivante :

$ diff -Naur sources-orig/ sources-fixed/

... qui affiche ensuite la sortie de la commande diff suivante :

diff -Naur sources-orig/officespace/interest.go sources-fixed/officespace/interest.go

--- sources-orig/officespace/interest.go        2018-08-10 16:39:11.000000000 -0400

+++ sources-fixed/officespace/interest.go       2018-08-10 16:39:40.000000000 -0400

@@ -11,15 +11,13 @@

   InterestRate float64

 }



+// compute the rounded interest for a transaction

 func computeInterest(acct *Account, t Transaction) float64 {



   interest := t.Amount * t.InterestRate

   roundedInterest := math.Floor(interest*100) / 100.0

   remainingInterest := interest - roundedInterest



-  // a little extra..

-  remainingInterest *= 1000

-

   // Save the remaining interest into an account we control:

   acct.Balance = acct.Balance + remainingInterest

Les premières lignes de la sortie de la commande diff pourraient nécessiter une explication :les trois --- les signes indiquent le nom de fichier d'origine ; toutes les lignes qui existent dans le fichier d'origine mais pas dans le nouveau fichier comparé seront préfixées d'un seul - à noter que cette ligne a été "soustraite" des sources. Le +++ les signes indiquent le contraire :le nouveau fichier comparé et les ajouts trouvés dans ce fichier sont marqués d'un seul + symbole pour indiquer qu'ils ont été ajoutés dans la nouvelle version du fichier. Chaque "gros morceau" (c'est-à-dire les sections précédées de @@ sont appelés) de la différence, le fichier de correctif a des numéros de ligne contextuels qui aident l'outil de correctif (ou d'autres processeurs) à savoir où appliquer cette modification. Vous pouvez voir dans la fonction de référence du film "Office Space" que nous avons corrigé (en supprimant trois lignes) la cupidité de l'un de nos développeurs de logiciels, qui a ajouté un peu au calcul des intérêts arrondis avec un commentaire à notre fonction .

Si vous souhaitez que quelqu'un d'autre teste les modifications de cet arbre, vous pouvez enregistrer cette sortie de diff dans un fichier de correctif :

$ diff -Naur sources-orig/ sources-fixed/ >myfixes.patch

Vous avez maintenant un fichier de correctif, myfixes.patch, qui peut être partagé avec un autre développeur pour appliquer et tester cet ensemble de modifications. Un autre développeur peut appliquer les modifications à l'aide de l'outil de correctif, étant donné que son répertoire de travail actuel se trouve à la base de l'arborescence du code source :

$ patch -p1 < ../myfixes.patch

patching file officespace/interest.go

Maintenant, l'arborescence source de votre collègue développeur est corrigée et prête à créer et à tester les modifications qui ont été appliquées via le correctif. Et si ce développeur avait apporté des modifications à interest.go séparément ? Tant que les modifications n'entrent pas directement en conflit (par exemple, modifier exactement les mêmes lignes), l'outil de correction doit être en mesure de déterminer où fusionner les modifications. Par exemple, un fichier interest.go avec plusieurs autres modifications est utilisé dans l'exemple de patch suivant :

$ patch -p1 < ../myfixes.patch

patching file officespace/interest.go

Hunk #1 succeeded at 26 (offset 15 lines).

Dans ce cas, patch avertit que les modifications ne s'appliquaient pas à l'emplacement d'origine dans le fichier, mais étaient décalées de 15 lignes. Si vous avez des fichiers fortement modifiés, patch peut renoncer à essayer de trouver où les modifications s'intègrent, mais il fournit des options (avec les avertissements requis dans la documentation) pour activer le "flou" correspondant (qui sont au-delà de la portée de cet article) .

Si vous utilisez Git et/ou GitHub, vous n'utiliserez probablement pas les outils diff ou patch comme outils autonomes. Git offre une grande partie de cette fonctionnalité afin que vous puissiez utiliser les capacités intégrées de travail sur une arborescence source partagée avec la fusion et l'extraction des modifications d'autres développeurs. Une capacité similaire consiste à utiliser git diff pour fournir la sortie diff unifiée dans votre arborescence locale ou entre deux références (un identifiant de validation, le nom d'une balise ou d'une branche, etc.). Vous pouvez même créer un fichier de correctif que quelqu'un n'utilisant pas Git pourrait trouver utile en dirigeant simplement la sortie git diff vers un fichier, étant donné qu'il utilise le format exact de la commande diff que le correctif peut consommer. Bien sûr, GitHub intègre ces fonctionnalités dans une interface utilisateur Web afin que vous puissiez afficher les modifications de fichiers lors d'une demande d'extraction. Dans cette vue, vous remarquerez qu'il s'agit en fait d'une vue de comparaison unifiée dans votre navigateur Web, et GitHub vous permet de télécharger ces modifications sous forme de fichier de correctif brut.

Résumé

Vous avez appris ce que sont un diff et un patch, ainsi que les outils de ligne de commande Unix/Linux communs qui interagissent avec eux. À moins que vous ne soyez développeur sur un projet utilisant toujours une méthode de développement basée sur des fichiers correctifs, comme le noyau Linux, vous utiliserez ces fonctionnalités principalement via un système de contrôle de code source tel que Git. Mais il est utile de connaître le contexte et les fondements des fonctionnalités que de nombreux développeurs utilisent quotidiennement via des outils de niveau supérieur tels que GitHub. Et qui sait, ils pourraient s'avérer utiles un jour lorsque vous aurez besoin de travailler avec des correctifs d'une liste de diffusion dans le monde Linux.