Úvod do diffů a patchů

Pokud jste někdy pracovali na rozsáhlé kódové základně s distribuovaným modelem vývoje, pravděpodobně jste slyšeli lidi říkat věci jako „Sue právě poslala opravu“ nebo „Rajiv kontroluje rozdíl“. Možná pro vás byly tyto pojmy nové a zajímalo vás, co znamenají. Open source zde měl vliv, protože hlavním vývojovým modelem velkých projektů od webového serveru Apache po jádro Linuxu byly po celou dobu své existence vývojové projekty založené na „patch“. Ve skutečnosti jste věděli, že název Apache pochází ze sady oprav, které byly shromážděny a porovnány s původním zdrojovým kódem serveru NCSA HTTPd?

Možná si myslíte, že je to folklór, ale první zachycení webu Apache tvrdí, že název byl odvozen z této originální kolekce „náplastí“; tedy APA tCH y server, který byl poté zjednodušen na Apache.

Ale dost historických drobností. Co přesně jsou tyto záplaty a rozdíly o kterém vývojáři mluví?

Za prvé, pro účely tohoto článku předpokládejme, že tyto dva termíny odkazují na jednu a tutéž věc. „Diff“ je jednoduše zkratka pro „rozdíl“; unixový nástroj se stejným názvem odhalí rozdíl mezi jedním nebo více soubory. Níže se podíváme na příklad nástroje pro rozdíl.

„Záplata“ odkazuje na specifickou kolekci rozdílů mezi soubory, které lze použít na strom zdrojového kódu pomocí unixové utility diff. Můžeme tedy vytvořit diffy (nebo záplaty) pomocí nástroje diff a aplikovat je na neopravenou verzi stejného zdrojového kódu pomocí nástroje záplaty. Pomineme-li (a porušuji své pravidlo už žádné historické triviality), slovo „záplata“ pochází z fyzického zakrývání otvorů pro děrné štítky za účelem provádění softwarových změn v raných počítačových dnech, kdy děrné štítky představovaly program prováděný procesorem počítače. Obrázek níže, který se nachází na této stránce Wikipedie popisující softwarové záplaty, ukazuje tento původní koncept „záplatování“:

Nyní, když máte základní znalosti o záplatách a rozdílech, pojďme prozkoumat, jak vývojáři softwaru tyto nástroje používají. Pokud jste nepoužívali systém řízení zdrojového kódu jako Git nebo Subversion, připravím půdu pro vývoj většiny netriviálních softwarových projektů. Pokud uvažujete o životě softwarového projektu jako o sadě akcí podél časové osy, můžete si vizualizovat změny softwaru – jako je přidání funkce nebo funkce do souboru zdrojového kódu nebo oprava chyby – objevující se na různých místech časovou osu, přičemž každý samostatný bod představuje stav všech souborů zdrojového kódu v daném čase. Tyto body změny budeme nazývat „závazky“ pomocí stejné nomenklatury, kterou používá dnešní nejpopulárnější nástroj pro kontrolu zdrojového kódu, Git. Chcete-li vidět rozdíl mezi zdrojovým kódem před a po určitém odevzdání nebo mezi mnoha odevzdáními, můžete použít nástroj, který nám ukáže rozdíly nebo rozdíly.

Pokud vyvíjíte software pomocí stejného nástroje pro řízení zdrojového kódu, Git, můžete mít ve svém lokálním systému změny, které chcete poskytnout ostatním, aby je případně přidali jako potvrzení do svého vlastního stromu. Jedním ze způsobů, jak poskytnout místní změny ostatním, je vytvořit rozdíl změn vašeho místního stromu a poslat tuto „záplatu“ ostatním, kteří pracují na stejném zdrojovém kódu. To umožňuje ostatním opravovat svůj strom a vidět strom zdrojového kódu s aplikovanými změnami.

Linux, Git a GitHub

Tento model sdílení záplatových souborů je způsob, jakým dnes komunita linuxového jádra funguje ohledně navrhovaných změn. Pokud se podíváte do archivů některé z populárních e-mailových konferencí linuxového jádra – primární je LKML, ale další zahrnují linux-containers, fs-devel, Netdev, abychom jmenovali alespoň některé – najdete mnoho vývojářů, kteří zveřejňují záplaty, které přejete si, aby jiní zkontrolovali, otestovali a případně vnesli do oficiálního stromu Git linuxového jádra v určitém okamžiku. Je mimo rámec tohoto článku podrobněji probírat Git, systém pro řízení zdrojového kódu napsaný Linusem Torvaldsem, ale stojí za zmínku, že Git umožňuje tento distribuovaný vývojový model, který umožňuje, aby záplaty žily odděleně od hlavního úložiště, a vtahování do různých stromů a sledování jejich specifického vývojového toku.

Než budeme pokračovat, nemůžeme ignorovat nejoblíbenější službu, ve které jsou záplaty a rozdíly relevantní:GitHub. Vzhledem k jeho názvu můžete pravděpodobně hádat, že GitHub je založen na Git, ale nabízí pracovní postup založený na webu a API kolem nástroje Git pro vývoj distribuovaných open source projektů. Jedním z hlavních způsobů sdílení záplat na GitHubu není e-mail, jako je tomu u linuxového jádra, ale vytvoření žádosti o stažení . Když provedete změny ve své vlastní kopii stromu zdrojového kódu, můžete tyto změny sdílet vytvořením požadavku na stažení proti běžně sdílenému úložišti pro daný softwarový projekt. GitHub dnes používá mnoho aktivních a populárních open source projektů, jako je Kubernetes, Docker, Container Network Interface (CNI), Istio a mnoho dalších. Ve světě GitHubu mají uživatelé tendenci používat webové rozhraní ke kontrole rozdílů nebo oprav, které obsahují požadavek na stažení, ale stále můžete přistupovat k nezpracovaným souborům oprav a používat je na příkazovém řádku pomocí nástroje pro opravy.

Začněte pracovat

Nyní, když jsme probrali opravy a rozdíly a jak se používají v oblíbených komunitách nebo nástrojích s otevřeným zdrojovým kódem, pojďme se podívat na několik příkladů.

První příklad obsahuje dvě kopie zdrojového stromu a jedna obsahuje změny, které chceme vizualizovat pomocí obslužného programu diff. V našich příkladech se podíváme na „sjednocené“ rozdíly, protože to je očekávaný pohled na záplaty ve většině moderního světa vývoje softwaru. Další informace o možnostech a způsobech, jak vytvořit rozdíly, najdete na manuálové stránce rozdílů. Původní zdrojový kód je umístěn v sources-orig a naše druhá, upravená kódová základna je umístěna v adresáři s názvem sources-fixed. Chcete-li zobrazit rozdíly ve formátu jednotného rozdílu ve vašem terminálu, použijte následující příkaz:

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

...který pak zobrazí následující výstup příkazu diff:

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

Prvních pár řádků výstupu příkazu diff by mohlo sloužit k vysvětlení:Tři --- znaky ukazují původní název souboru; všechny řádky, které existují v původním souboru, ale ne v porovnávaném novém souboru, budou mít předponu - poznamenat, že tento řádek byl „odečten“ ze zdrojů. +++ znaky ukazují opak:Porovnaný nový soubor a doplňky nalezené v tomto souboru jsou označeny jedním + symbol, který ukazuje, že byly přidány do nové verze souboru. Každý „kus“ (to jsou sekce s předponou @@ jsou volány) rozdílového záplatového souboru má kontextová čísla řádků, která pomáhají opravnému nástroji (nebo jiným procesorům) vědět, kde tuto změnu použít. Z referenční funkce filmu „Office Space“ můžete vidět, že jsme opravili (odstraněním tří řádků) nenasytnost jednoho z našich softwarových vývojářů, který přidal trochu do výpočtu zaokrouhleného úroku spolu s komentářem k naší funkci .

Pokud chcete, aby někdo jiný otestoval změny z tohoto stromu, můžete tento výstup z diff uložit do souboru opravy:

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

Nyní máte opravný soubor myfixes.patch, který lze sdílet s jiným vývojářem, aby mohl použít a otestovat tuto sadu změn. Kolega vývojář může použít změny pomocí nástroje pro opravy, protože jeho aktuální pracovní adresář je v základu stromu zdrojového kódu:

$ patch -p1 < ../myfixes.patch

patching file officespace/interest.go

Nyní je zdrojový strom vašeho kolegy vývojáře opraven a připraven k vytvoření a testování změn, které byly aplikovány prostřednictvím opravy. Co kdyby tento vývojář provedl změny na interest.go samostatně? Dokud změny nejsou v přímém konfliktu – například nezměníte stejné přesné řádky – měl by být opravný nástroj schopen vyřešit, kam sloučit změny. Jako příklad je použit soubor interest.go s několika dalšími změnami. následující příklad spuštění opravy:

$ patch -p1 < ../myfixes.patch

patching file officespace/interest.go

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

V tomto případě patch varuje, že změny se neprojevily v původním umístění v souboru, ale byly posunuty o 15 řádků. Pokud jste výrazně změnili soubory, patch se může vzdát pokusu najít, kam změny zapadají, ale poskytuje možnosti (s požadovanými varováními v dokumentaci) pro zapnutí odpovídající „fuzziness“ (které jsou nad rámec tohoto článku). .

Pokud používáte Git a/nebo GitHub, pravděpodobně nebudete používat nástroje diff nebo patch jako samostatné nástroje. Git nabízí velkou část této funkce, takže můžete využít vestavěné možnosti práce na sdíleném zdrojovém stromu se slučováním a stahováním změn jiných vývojářů. Jedna podobná schopnost je použít git diff k poskytnutí jednotného výstupu diff ve vašem místním stromu nebo mezi libovolnými dvěma odkazy (identifikátor odevzdání, název značky nebo větve atd.). Můžete dokonce vytvořit soubor záplaty, který může být užitečný pro někoho, kdo nepoužívá Git, jednoduchým propojením výstupu git diff do souboru, protože používá přesný formát příkazu diff, který může záplata spotřebovat. GitHub samozřejmě přebírá tyto možnosti do webového uživatelského rozhraní, takže můžete zobrazit změny souborů na vyžádání. V tomto zobrazení si všimnete, že jde v podstatě o sjednocené zobrazení rozdílů ve vašem webovém prohlížeči a GitHub vám umožňuje stáhnout tyto změny jako nezpracovaný soubor opravy.

Shrnutí

Dozvěděli jste se, co je to rozdíl a oprava, stejně jako běžné nástroje příkazového řádku Unix/Linux, které s nimi komunikují. Pokud nejste vývojářem projektu, který stále používá metodu vývoje založenou na záplatových souborech – jako je linuxové jádro – budete tyto schopnosti využívat primárně prostřednictvím systému řízení zdrojového kódu, jako je Git. Je však užitečné znát pozadí a základy funkcí, které mnoho vývojářů denně používá prostřednictvím nástrojů vyšší úrovně, jako je GitHub. A kdo ví – možná se někdy budou hodit, když budete ve světě Linuxu potřebovat pracovat s opravami z mailing listu.