8.2 Anpassa Git - Git‑attribut

Ett smart trick du kan använda med Git‑attribut är att tala om för Git vilka filer som är binära (i fall där den annars inte kan lista ut det) och ge Git särskilda instruktioner om hur dessa filer ska hanteras. Till exempel kan vissa textfiler vara maskinskapade och svåra att diffa, medan vissa binära filer kan diffas. Du får se hur du talar om för Git vilket som är vilket.

Nyckelordsexpansion i SVN‑ eller CVS‑stil efterfrågas ofta av utvecklare som är vana vid de systemen. Huvudproblemet i Git är att du inte kan modifiera en fil med information om incheckningen efter att du checkat in, eftersom Git först beräknar filens kontrollsumma. Du kan däremot injicera text i en fil när den läggs ut och ta bort den igen innan den köas. Git‑attribut ger dig två sätt att göra detta.

Först kan du automatiskt injicera SHA‑1‑kontrollsumman för en blob i ett $Id$‑fält i filen. Om du sätter detta attribut på en fil eller uppsättning filer kommer Git nästa gång du växlar till den grenen att ersätta fältet med blob‑SHA‑1:an. Det är viktigt att notera att det inte är SHA‑1:an för incheckningen, utan för blobben själv. Lägg följande rad i din .gitattributes‑fil:

Lägg till en $Id$‑referens i en testfil:

Nästa gång du lägger ut filen injicerar Git blob‑SHA‑1:an:

Detta resultat har dock begränsad nytta. Om du har använt nyckelordssubstitution i CVS eller Subversion kan du inkludera en datumstämpel – SHA‑1:an är inte särskilt hjälpsam, eftersom den är ganska slumpmässig och du kan inte se om en SHA‑1 är äldre eller nyare än en annan bara genom att titta på dem.

Det visar sig att du kan skriva egna filter för att göra substitutioner i filer vid incheckning/utläggning. Dessa kallas “clean”‑ och “smudge”‑filter. I .gitattributes‑filen kan du sätta ett filter för vissa sökvägar och sedan sätta upp skript som bearbetar filer strax innan de läggs ut (“smudge”, se “smudge”‑filtret körs vid utläggning) och strax innan de köas (“clean”, se “clean”‑filtret körs när filer köas). Dessa filter kan ställas in för att göra många olika saker.

Det ursprungliga incheckningsmeddelandet för denna funktion ger ett enkelt exempel på att köra all C‑källkod genom programmet indent innan incheckning. Du kan ställa in det genom att sätta filterattributet i din .gitattributes‑fil så att \*.c‑filer filtreras med “indent”‑filtret:

Berätta sedan för Git vad “indent”‑filtret gör vid smudge och ren:

I detta fall kommer Git, när du checkar in filer som matchar *.c, att köra dem genom indent innan den köar dem och sedan köra dem genom cat innan den lägger ut dem tillbaka till disk. Programmet cat gör i praktiken ingenting: det spottar ut samma data som det får in. Den här kombinationen filtrerar alltså all C‑källkod genom indent innan incheckning.

Ett annat intressant exempel är $Date$‑nyckelordsexpansion i RCS‑stil. För att göra detta korrekt behöver du ett litet skript som tar ett filnamn, tar reda på senaste incheckningsdatum för projektet och stoppar in datumet i filen. Här är ett litet Ruby‑skript som gör det:

Skriptet gör bara att ta senaste incheckningsdatum från git log, stoppa in det i alla $Date$‑strängar det ser på stdin och skriva ut resultatet – det bör vara enkelt att göra i vilket språk du än föredrar. Du kan kalla filen expand_date och lägga den i din sökväg. Nu behöver du sätta upp ett filter i Git (kalla det dater) och tala om för det att använda filtret expand_date för att smudge‑bearbeta filerna vid utläggning. Du använder ett Perl‑uttryck för att städa upp detta vid incheckning:

Den här Perl‑snutten tar bort allt den ser i en $Date$‑sträng, för att komma tillbaka till utgångsläget. Nu när filtret är klart kan du testa det genom att sätta upp ett Git‑attribut för den filen som aktiverar filtret och skapa en fil med ditt $Date$‑nyckelord:

Om du checkar in ändringarna och lägger ut filen igen ser du att nyckelordet ersätts korrekt:

Du ser hur kraftfull tekniken kan vara för anpassade tillämpningar. Du måste dock vara försiktig, eftersom .gitattributes‑filen checkas in och skickas runt med projektet, men drivrutinen (i det här fallet dater) gör det inte, så det fungerar inte överallt. När du utformar dessa filter bör de kunna misslyckas snyggt och ändå låta projektet fungera korrekt.

Git‑attributdata gör det också möjligt att göra intressanta saker när du exporterar ett arkiv av ditt projekt.

Du kan också använda Git‑attribut för att tala om för Git att använda olika sammanslagningsstrategier för specifika filer i ditt projekt. Ett mycket användbart alternativ är att tala om för Git att inte försöka sammanfoga vissa filer när de har konflikter, utan i stället använda din sida av sammanslagningen framför någon annans.

Det här är hjälpsamt om en gren i projektet har glidit isär eller är specialiserad, men du vill kunna sammanfoga in ändringar från den och samtidigt ignorera vissa filer. Säg att du har en databasinställningsfil som heter database.xml som är olika i två grenar, och du vill sammanfoga den andra grenen utan att stöka till databasfilen. Du kan ställa in ett attribut så här:

Och sedan definiera en tom "ours"‑sammanslagningsstrategi med:

Om du sammanfogar den andra grenen ser du i stället för sammanslagningskonflikter i database.xml något som detta:

I det här fallet behåller database.xml den version du redan hade.