Com aplicar pegats al codi amb la utilitat patch

Si treballes amb GNU/Linux i desenvolupes o mantens programari, tard o d'hora toparàs amb els pegats de codi . Potser voleu enviar una correcció a l'autor d'un projecte, compartir canvis amb un company sense fer servir un dipòsit remot o adaptar un driver antic a un nucli modern. En tots aquests casos, crear i aplicar pegats amb les utilitats diff i patch és una solució senzilla, potent i molt usada al món Unix.

En aquest article veurem, amb calma i molt detall, com generar pegats i com aplicar-los usant tant les eines clàssiques de GNU/Linux (diff i patch) com la seva integració en fluxos de treball amb Git . A més, comentarem altres escenaris on es parlen de “pegats” (com a sistemes empresarials tipus Sage X3 o actualitzacions de programari) perquè tinguis una visió completa de què és un pegat informàtic i com funciona en diferents contextos.

Què és un pegat de codi en informàtica?

En un context de desenvolupament de programari, quan parlem d'un pegat informàtic ens referim a un conjunt de canvis que s'apliquen sobre un o més fitxers ja existents. Aquests canvis poden estar orientats a corregir errors, afegir funcionalitats noves, actualitzar el comportament d'un programa o fins i tot eliminar parts antigues del codi que ja no tenen sentit.

Un pegat no és més que un fitxer de text pla que descriu amb precisió quines línies cal afegir, eliminar o modificar en determinats fitxers. A partir d'un fitxer original i aquest fitxer de pegat, l'eina adequada (com patch o les ordres de Git) és capaç de reconstruir la versió modificada sense necessitat d'enviar tot el fitxer nou complet.

Aquest mecanisme és especialment útil en projectes de programari lliure , en què col·laboradors externs poden enviar correccions o millores sense accés directe al repositori. Simplement creen un pegat amb els seus canvis i l'envien al mantenidor perquè el revisi i l'apliqui si ho considera oportú.

Exemple pràctic: modificar un script a GNU/Linux

Imagina que tens un petit script Bash anomenat actualizar.sh que utilitzes per automatitzar una tasca. T'adones que podries millorar-lo o que conté errors tipogràfics als missatges que mostra per pantalla. No vols picar l'original sense més ni més, així que segueixes un enfocament ordenat:

• Feu una còpia del fitxer original, per exemple, actualitzar.sh.nou.
• Editeu aquesta còpia i apliqueu les modificacions que cregueu oportunes: afegir funcions, corregir textos, eliminar parts redundants…
• Un cop estàs satisfet amb el resultat, generes un parche que reculli exactament les diferències entre el fitxer original i el modificat.

El resultat serà un fitxer amb extensió .patch que podràs enviar a una altra persona (per correu, missatgeria, adjunt en un issue, etc.) perquè integri aquests canvis al seu propi codi original de forma automàtica.

Creació d'un pegat amb l'ordre diff

La utilitat diff compara dos fitxers o directoris i mostra les diferències entre ells. És la base per generar pegats a GNU/Linux. En el cas més senzill, podeu crear un pegat amb una ordre d'aquest estil:

diff -u viejo.txt nuevo.txt > cambios.patch

En aquest exemple, vell.txt és el fitxer original i nou.txt és la versió modificada que conté els canvis que vols compartir. Mitjançant la redirecció amb >, tot el resultat de diff es guarda en canvis.patch , que és el fitxer de pegat que després aplicaràs sobre la versió original.

L'opció -u genera un pegat unificat amb context: inclou diverses línies abans i després de cada canvi. Això facilita tant la lectura humana com el treball de l'eina patch, que pot localitzar millor on aplicar les modificacions fins i tot si el fitxer no coincideix al 100% amb l'original.

En molts entorns es recomana utilitzar un conjunt més ampli d'opcions, com ara -Naur :

• -N: tracta els fitxers que falten com a buits (útil quan es creen o eliminen fitxers).
• -a: força el tractament com a text fins i tot si diff sospita que pugui ser binari.
• -u: genera el diff en format unificat, que és l'estàndard de facto per a pegats.
• -r: recorre directoris de forma recursiva, comparant subcarpetes.

Un exemple típic per generar un pegat de tot un projecte podria ser:

diff -Naur proyecto_original/ proyecto_modificado/ > proyecto.patch

Amb aquesta ordre obtens un únic fitxer de pegat que descriu totes les diferències entre ambdues còpies del projecte, incloent fitxers nous, fitxers esborrats i canvis en el contingut.

Com interpretar el contingut d'un fitxer .patch

Si obris un fitxer de pegat amb el teu editor de text preferit, veuràs que segueix una estructura força clara. Per exemple, una cosa semblant a això:

$ diff -Naur cello.c.orig cello.c
--- cello.c.orig 2016-05-26 17:21:30.478523360 -0500
+++ cello.c      2016-05-27 14:53:20.668588245 -0500
@@ -1,6 +1,6 @@
 #include<stdio.h>
 int main(void){
- printf("Hello World!\n");
+ printf("Hello World from my very first patch!\n");
  return 0;
 }
\ No newline at end of file

En aquest fragment podeu observar diversos elements clau en el format unificat:

• Les línies que comencen per - y + + + indiquen, respectivament, el fitxer original i el fitxer modificat.
• Els blocs que comencen amb @@ assenyalen el rang de línies afectat al fitxer original i al nou.
• Les línies amb - a l'inici són línies que es eliminen del fitxer original.
• Les línies amb + a l'inici representen les línies que es afegeixen al fitxer resultant.
• Les línies sense signe inicial (o amb espai) són context: per elles, l'eina entén on encaixen els canvis.

Encara que pugui semblar un format una mica cru, una vegada t'hi acostumes resulta molt intuïtiu i et permet revisar d'una ullada què s'ha canviat i on i, si cal, provar canvis en un entorn aïllat sense haver d'obrir els fitxers originals i els modificats per separat.

Aplicar un pegat amb l'ordre patch

L'eina complementària a diff és patch , que s'encarrega de llegir un fitxer .patch i realitzar les modificacions necessàries sobre un o diversos fitxers existents. L'ús bàsic és molt directe:

patch < cambios.patch

En aquest cas, patch llegeix el contingut des de l'entrada estàndard i, gràcies a la informació inclosa al pegat (les línies — i +++ amb els noms del fitxer), sap exactament sobre quin fitxer ha d'aplicar els canvis . Si el fitxer no és on s'espera, patch us pot preguntar per la ruta correcta o fallar amb un missatge d'error; és bona pràctica en estratègies dactualització preparar lentorn abans daplicar pegats.

També podeu especificar els fitxers de manera explícita, per exemple per a un cas molt senzill d'un sol fitxer:

patch viejo.txt < cambios.patch

En aquest mode, indiqueu a patch quin és el fitxer base i el pegat s'aplica sobre ell. Si tot va bé, al final tindràs un vell.txt modificat que coincideix amb la versió nou.txt amb què vas crear el pegat.

Gestionar rutes amb l'opció -p de patch

Quan els pegats es generen entre directoris complets, el nom del fitxer dins del .patch sol incloure la ruta relativa al fitxer, com:

--- /tmp/blogcrearpatchsyaplicarlosenlinux/viejo.txt
+++ /tmp/blogcrearpatchsyaplicarlosenlinux/viejo.txt

Si a la teva màquina els fitxers no estan en aquesta ruta exacta, no és pràctic anar editant el pegat a mà per ajustar les rutes. Per això hi ha el paràmetre -p de patch, que permet “retallar” directoris del principi de la ruta fins que encaixi amb la teva estructura de carpetes.

Per exemple:

• patch -p0 < canvis.patch manté la ruta completa /tmp/blogcrearpatchsiaplicar-losenlinux/vell.txt.
• patch -p1 < canvis.patch elimina el primer component (/tmp) i es queda amb blogcrearpatchsiaplicar-losenlinux/vell.txt.
• patch -p2 < canvis.patch elimina els dos primers directoris (/tmp i blogcrearpatchsiaplicar-losenlinux/), quedant sol vell.txt com a ruta.

Gràcies a aquesta opció, podeu aplicar pegats generats en altres entorns o amb diferents jerarquies de directoris sense tocar el contingut del fitxer .patch. És una solució molt més neta que editar les rutes a mà i evita errors ximples.

Ús de pegats amb Git: git diff, git apply i git format-patch

Encara que diff i patch són la base històrica, en el dia a dia molts desenvolupadors treballen amb Git , que incorpora les seves pròpies ordres per crear i aplicar pegats de forma integrada amb el repositori.

Dins un repositori Git, un pegat segueix sent un fitxer de text pla amb diferències en format unificat. L'avantatge és que Git sap en tot moment què ha canviat, qui ho ha modificat i en quins commits, així que pot generar pegats de diferents maneres segons el que necessitis compartir.

Crear un pegat amb canvis sense commetre

Si heu tocat diversos fitxers a la vostra còpia local, però encara no heu fet commit , podeu desar aquests canvis en un fitxer de pegat per compartir-los amb algú o conservar-los sense necessitat de pujar-los a un remot:

git diff > cambios.patch

Aquesta comanda captura totes les diferències entre el teu working directory i el darrer commit, i les bolca a un fitxer .patch que després una altra persona podrà aplicar sobre la mateixa versió del repositori.

Crear un pegat a partir d'un commit existent

Quan ja has fet un commit i vols compartir únicament aquest conjunt de canvis, és més còmode recórrer a git format-patch :

git format-patch -1 HEAD

Amb aquesta ordre es genera un fitxer .patch (o .patch/.mbox) que conté tota la informació del darrer commit: diffs, metadades, autor, missatge de commit, etc. És el format clàssic que es fa servir per enviar pegats per correu en molts projectes de codi obert.

També pots indicar un rang de commits per generar una sèrie de pegats, un per commit, si necessites que el receptor els apliqui de manera seqüencial respectant la història de canvis.

Aplicar un pegat a Git

Si el que reps és un simple fitxer de diff (creat amb git diff o diff clàssic), en un repositori Git normalment usaràs:

git apply cambios.patch

Aquesta ordre intentarà aplicar els canvis sobre el vostre arbre de treball actual, sense crear cap commit automàticament. Per mantenir un sistema estable , després podràs revisar i fer commit de les modificacions com prefereixis.

Abans de llançar-te, és molt recomanable verificar si el pegat encaixa bé al teu arbre actual usant l'opció –check :

git apply --check cambios.patch

Si no apareixen errors, vol dir que el pegat es pot aplicar sense conflictes. Si hi ha problemes de compatibilitat (arxius que han canviat massa, context que no coincideix, etc.), Git t'ho indicarà i podràs decidir si actualitzes la teva branca, demanes a l'autor que faci el pegat sobre la teva versió o resols conflictes manualment.

Aplicar pegats tipus “sèrie de commits” amb git am

Quan el pegat procedeix de git format-patch o d'alguns sistemes com GitHub (per exemple, pegats descarregats d'una pull request), l'habitual és fer servir git am , que aplica el pegat i genera directament els commits corresponents:

git am --signoff < patchName.patch

El paràmetre –signoff afegeix una línia “Signed-off-by” al missatge de commit, cosa que certes comunitats exigeixen per motius de traçabilitat legal o d'autoria. Durant aquest procés poden aparèixer advertiments, però mentre no hi hagi errors bloquejants, el pegat s'incorporarà a la branca actual com un o més commits nous.

Si en algun moment has de revertir un pegat aplicat amb git apply , pots fer servir l'opció -R per intentar desfer-ho:

git apply -R patchName.patch

Aquesta ordre intenta aplicar el pegat en sentit invers, eliminant les línies afegides i restaurant les que van ser esborrades, sempre que el context no hagi canviat en excés.

Verificar compatibilitat i conflictes de pegats

Un dels riscos en treballar amb pegats és que no encaixin bé amb l'estat actual del codi: potser l'arxiu ha canviat molt des que es va generar el pegat, o estàs intentant combinar diversos pegats que toquen les mateixes zones del codi de manera incompatible.

En fluxos de treball amb Git, ja hem vist que podeu executar git apply –check per comprovar si un pegat es podria aplicar sense errors abans de modificar res. En altres entorns, com a projectes específics (per exemple, motors de joc com Intersect o plataformes empresarials), hi sol haver una funció de “provar pegats” que n'analitza l'impacte i genera un informe de compatibilitat; a més, és habitual crear snapshots seguint bones pràctiques de snapshots abans d'integrar-los de manera definitiva.

Convé que només instal·lis pegats procedents de fonts de confiança , ja que qualsevol modificació del codi font pot introduir bugs, problemes de rendiment o fins i tot vulnerabilitats de seguretat si el pegat no està ben escrit.

Pegats en sistemes empresarials: exemple de Sage X3

Més enllà del món del desenvolupament pur, moltes aplicacions empresarials complexes, com les que usen la tecnologia SAFE X3 (per exemple, Sage X3), incorporen mecanismes propis per distribuir correccions i evolucions funcionals en forma de fitxers de pegat.

En aquest tipus de sistemes, un pegat pot incloure objectes molt variats : pantalles, definicions de taules, codis dactivitats, tipus de dades, menús, capítols de missatges, processos automatitzats, peticions dexecució, dades addicionals, etc. La lògica és semblant a la dels pegats de codi, però aplicada a elements de configuració i estructura interna de l'ERP.

Els fitxers de pegat solen seguir convencions de nom estrictes , com per exemple:

• Correccions estàndard amb noms del tipus P_nnnn_vvv.dat, on nnnn és un número seqüencial i vvv indica la versió mínima del producte sobre la qual es pot aplicar.
• Pegats de documentació amb noms tipus Dy_nnnnn_vvv_ppp.dat, on i abreuja el producte, nnnnn és un nombre cronològic, vvv és la versió i ppp el codi de legislació.

La pròpia aplicació s'encarrega de verificar la seqüencialitat, la versió mínima requerida, la integritat del fitxer i si el mòdul funcional afectat està implantat al dossier (entorn) on vols integrar-lo. Si falten pedaços intermedis, si el fitxer està corrupte o si la versió del producte és massa antiga, es registren errors en un fitxer de traça.

En molts casos, la integració d'un pegat no només toca el codi, sinó també el diccionari de dades i la base de dades . Per exemple, si el pegat inclou una taula nova o modifica una existent, el sistema pot necessitar validar la taula, recrear-la, actualitzar índexs i estadístiques, etc. Depenent del tipus de canvi (afegir camps al final o entre camps ja existents), les estadístiques de la base es mantenen o es perden i es reconstrueixen.

La gestió d'aquests pegats sol realitzar-se des d'una funció específica dins de l'ERP (com PATCHT a Sage X3), que permet llançar la integració en mode interactiu o en mode batch per a diversos dossiers alhora (normalment fins a un màxim configurat). En acabar, es genera un fitxer de traça que convé revisar per identificar qualsevol incidència.

En el cas dels pegats de documentació, la seva integració actualitza el diccionari de documentació , però no els documents finals publicats. Perquè aquests es reflecteixin al servidor de documentació, cal llançar processos de generació de documentació , sovint diferenciant tipus de dades (APM, AML, ATB, ATY) i respectant un ordre concret.

Com es relacionen els pegats amb les actualitzacions de programari

Quan en el dia a dia actualitzes un programa al teu sistema operatiu, és normal preguntar-se si el que fa el gestor de paquets és desinstal·lar tot i reinstal·lar, o si en realitat està aplicant una cosa semblant a un pegat. La resposta depèn molt de la tecnologia de distribució que es faci servir.

En els sistemes de paquets tradicionals (com deb a Debian/Ubuntu o rpm a Red Hat/Fedora), moltes actualitzacions consisteixen a instal·lar un paquet complet nou que conté tots els fitxers de la versió actualitzada. Tècnicament no és un pegat a l'estil de diff/patch, sinó un reemplaçament de fitxers . El gestor s'encarrega de treure els fitxers antics (o marcar-los com a obsolets) i col·locar-ne de nous, respectant en tant que sigui possible les configuracions de l'usuari.

No obstant això, en altres contextos -sobretot en entorns empresarials, jocs, sistemes encastats o algunes plataformes mòbils- s'usen mecanismes d' actualitzacions incrementals , on només es distribueixen els canvis respecte a la versió instal·lada. Això s'assembla molt més al concepte de pegat: s'entrega un fitxer que conté deltes (diferències) i un programa actualitzador que s'ocupa d'aplicar-los al binari o dades existents per produir la nova versió.

En sistemes operatius moderns també hi ha mètodes sofisticats com instantànies (snapshots), capes de només lectura i deltes binaris , que permeten reduir la mida de les descàrregues i augmentar la fiabilitat de les actualitzacions. Encara que per sota es faci servir un format diferent, la idea conceptual és molt similar a la dels pegats que veus amb diff i patch: partir d'un estat A, aplicar un conjunt de transformacions ben definides i obtenir un estat B sense haver de reconstruir-ho tot des de zero.

En definitiva, entendre com funcionen els pegats de codi amb eines com diff, patch i les ordres de Git et dóna un control enorme sobre com comparteixes i apliques canvis, des del petit script que ajustis a la teva màquina fins a entorns empresarials on es distribueixen evolucions completes en forma de fitxers de pegat; dominar aquestes tècniques et permet col·laborar de manera més eficient, diagnosticar millor els problemes de compatibilitat i moure't amb facilitat per qualsevol escenari on calgui transformar un codi o sistema ja existent sense reinstal·lar-lo del tot.