10 nivåer av Git-alias: från nybörjare till mellannivå

Visste du att Git kan anpassas efter dina behov på många olika sätt?

De främsta anledningarna till att skapa Git-alias kan vara en eller flera av följande:

• Optimera: Skapa genvägar för Git-kommandon som används ofta.

• Anpassa: Få Git att fungera som du vill eller stöd teamets överenskomna arbetssätt.

• Komma ihåg: Skapa lättmemorerade genvägar för komplexa operationer.

I första delen av min bloggserie tar jag med dig på en resa från de allra enklaste grunderna, med Git-alias som bara sparar dig från att skriva längre kommandon, till mer avancerade funktioner som även många erfarna Git-användare aldrig har använt.

Del två fortsätter därifrån och introducerar ännu mer avancerade koncept och verkligt ”udda” användningsområden för Git-alias, inklusive några rent galna exempel, innan vi går igenom alternativ för att lösa samma behov.

Genom att lära dig och förstå dessa tekniker – oavsett om du använder alias som du lånar från andra eller själv utforskar gränserna – blir du en effektivare och mer kompetent Git-användare och förhoppningsvis blir din vardag med Git roligare. På vägen lär du dig troligen också några tips och tricks och utforskar delar av Git som du inte ens visste fanns.

Vad är Git-alias och hur ställer vi in dem?

Git-alias ersätter Git-underkommandon, på samma sätt som exempelvis Bash-alias ersätter andra Bash-kommandon eller skript. Git låter dig helt enkelt definiera egna Git-kommandon som gör det du vill och som kan användas sömlöst tillsammans med de inbyggda kommandona.

Alias definieras i Git-konfigurationshierarkin, men eftersom vi vanligtvis vill att de ska fungera överallt på datorn är den globala konfigurationen deras naturliga hemvist.

Du kan lägga till alias antingen genom att redigera din globala konfigurationsfil direkt eller med kommandot git config.

Testa detta för att skapa ditt första enkla alias:

Detta lägger till en ny rad i avsnittet [alias] i din globala konfigurationsfil och skapar avsnittet om det inte redan finns. Låt oss titta:

För mer komplexa alias längre fram på resan rekommenderar jag att du helt enkelt öppnar ~/.gitconfig i den editor du föredrar och lägger till eller ändrar dina alias direkt där.

Nivå 1: Den late skrivaren

Okej, låt oss börja med den första nivån. Jag är lat och vill helt enkelt optimera hur jag skriver kommandon som jag använder hundratals gånger om dagen, eller hantera vanliga stavfel som jag ofta gör.

Vi har redan sett förslaget st ovan, men här är några fler vanliga exempel på enkla genvägar:

När det gäller alias för ”vanliga stavfel” är det en personlig preferens. Skapa alias för de kommandon som dina fingrar inte kan skriva. Min personliga nemesis är switch, men jag har bestämt mig för att alltid använda den korta varianten ”sw” som föreslås ovan, i stället för att skapa alias för alla möjliga stavfel jag kan göra i det ordet. Men här är några exempel som inspiration:

Vid det här laget funderar du kanske redan på vilka Git-kommandon som är bäst lämpade för alias. För flera år sedan kom jag på ett intressant svar. Precis som Git har även mitt skal (Bash, Zsh) stöd för alias. Därför skapade jag följande skalalias i mina konfigurationsfiler .bashrc och .zshrc:

Vissa av dem kanske redan är befintliga alias (här slog, st och glog), men de andra kan mycket väl vara bra kandidater för dig att ”förkorta” eller att komma ihåg att använda med alias du redan har skapat. Den enda anledningen till att jag använder ”git status” så ofta, trots mitt alias ”git st”, är att jag håller många Git-utbildningar där jag har bestämt mig för att använda de faktiska kommandona.

Nivå 2: Enkla alternativ för att slippa skriva dagliga flaggor

Då är det dags att höja volymen ett steg på Git-alias. Alias låter oss också lägga till ”alternativ” till de Git-kommandon vi skapar alias för, så låt oss se hur vi kan använda det.

Det vanligaste användningsfallet är att skapa enkla alias för vanliga varianter av utdata från Git log.

Till exempel:

Ett annat bra förslag är att använda den här funktionen för att skapa de där irriterande Git-kommandona som "saknas" och som du tycker borde ha funnits, där du kanske har svårt att komma ihåg exakt vilket kommando och vilket alternativ du behöver använda för att utföra den där mycket vanliga uppgiften.

Visserligen har många Git-användare kanske aldrig hört talas om dessa Git-kommandon och alternativ, än mindre använt dem. Det gör dessa alias antingen värdelösa eller till ett utmärkt inlärningstillfälle.

Nivå 3: Komplexa argument hjälper oss att komma ihåg sällan använda kommandon

Nästa steg på vår resa är att undersöka hur vi kan använda alias för kommandon som också har komplexa argument.

Hittills har vi främst fokuserat på alias för kommandon som används ofta, men eftersom vi nu kan förkorta betydligt mer komplexa kommandon kan det också vara användbart att gå åt andra hållet och använda alias för:

• Sällan använda Git-uppgifter som är svåra att komma ihåg.

• Att göra kommandon som är svåra att skriva smidigare.

Tillsammans gör detta att du kan använda bra Git-funktioner som du annars kanske inte skulle bry dig om.

Som du ser har jag beskrivit aliasen "inline" i exemplen ovan genom att använda möjligheten att lägga till #-kommentarer i din configfil. Det är inte bara för att göra exemplet enklare, utan också för att starkt rekommendera att du gör samma sak i din faktiska config. Det tog mig alldeles för många år att lära mig detta den hårda vägen, och nu har jag samlat på mig mängder av märkliga alias och andra inställningar vars syfte jag inte riktigt minns.

Låt oss titta på några mer specifika och ofta använda exempel från min samling. Den här gången visar jag faktiskt resultaten. Jag ska visa ett användbart diff-alias, men först vyn "före", där git diff körs på en markdown-fil.

Låt oss nu lägga till ett alias:

Och använda det i stället:

Det här är uppenbarligen mycket renare och lättare att förstå. Det är inte aliaset i sig som gör magin; det här är inbyggda funktioner i Git. Men aliaset gör det användbart i min vardag, eftersom jag inte orkar komma ihåg att skriva: git diff -w --word-diff=color --ignore-space-at-eol varje gång.

Låt oss definiera:

Det visade utdraget täcker mer än 3 000 commits i Tensorflow-repot genom att bara visa de commits som är "märkta" (taggar eller branch-huvuden).

För att avsluta den här nivån och smidigt leda in på nästa ska vi titta på vad som förmodligen är den mest värdefulla användningen av alias med komplexa argument: möjligheten att skapa ännu mer anpassade git log-kommandon som passar dina preferenser genom att använda egna format. Jag vill inte att detta ska bli en guide till de faktiska formateringsalternativen, så låt oss bara sätta i gång så förstår du snart. Allt detta dokumenteras utförligt i avsnittet Pretty formats i git help log.

Här är min dagliga favorit:

Nivå 4: Pretty formats – gör dina alias renare med återanvändbarhet

På den här nivån lämnar vi Git-aliasens närmaste område, och jag ska visa dig hur du använder den mindre kända funktionen med egna pretty formats för att rensa upp dina alias och göra dem betydligt mer återanvändbara.

(De faktiska aliasen var mycket längre, men hade alla samma formatsträng.)

Och många liknande. Det gjorde det verkligen irriterande varje gång jag ville justera formatet, färgsättningen och så vidare.

I dag, i nyare versioner av Git, kan alias referera till andra, så ovanstående kan förbättras avsevärt, till exempel:

Men det visar sig att det finns ett bättre alternativ.

(Se dokumentationen som länkas ovan för mer information.)

Alldeles för sent på min resa upptäckte jag att Git låter mig definiera egna anpassade "pretty"-format i Git-configen, men när jag hittade den här funktionen var den fantastisk!

Dessa format kan definieras i avsnittet [pretty] i din konfiguration (eller git config –global pretty.myformat …..) så här:

När jag har definierat dessa kan jag använda dem när som helst när jag kör ett Git log-kommando:

Det innebär också att jag kan skriva om alla mina märkliga log-alias så att de använder mitt eget pretty-format, och sedan har jag ett enda ställe att redigera när min smak förändras.

Ytterligare en fördel med att ha dessa pretty-format definierade är att jag också kan använda dem ”vid behov”, även när jag kör log-kommandon i stunden.

Nivå 5: Prefix – åsidosätt Git-beteendet för specifika Git-underkommandon

På nivå 5, för att avrunda den här delen av bloggserien, ska vi titta på en mycket okänd funktion i Git-alias som utnyttjar en annan ganska okänd funktion.

Det visar sig att Git-alias kan skicka alternativ inte bara till Git-underkommandot utan även till själva kommandot git. Och om du tänker: ”Jag visste inte att Git-kommandot hade alternativ”, är du förmodligen inte ensam.

Ett användbart och lättförklarat exempel är alternativet för att styra sidindelning. Som standard skickar Git all utdata som är längre än en skärm till less (eller någon annan konfigurerad pager), medan kortare utdata skrivs ut direkt. Men Git låter oss åsidosätta detta beteende om vi vill, till exempel:

Låt oss se hur det kan användas i ett alias. Till exempel:

Ett annat bra sätt att använda den här funktionen är tillsammans med Gits möjlighet att tillfälligt åsidosätta konfigurationsinställningar.

I Git kan du använda alternativet -c för att åsidosätta ett konfigurationsvärde enbart för detta kommando, dvs. git -c <config override> <subcommand>.

Detta kan också användas som ett alias:

Obs! Detta skiljer sig från att använda git commit --author= eftersom det anger identiteten för både författaren och den som gör commiten, vilket visas i följande exempel:

Vad händer härnäst i bloggserien om Git?

Jag har tagit dig igenom lite mer än grunderna i Git-alias. Vi har sett hur de kan vara otroligt användbara i det dagliga arbetet, för kommandon som vi använder ofta eller kommandon som vi använder så sällan att vi inte kommer ihåg dem. Vi har också gått lite utanför ramarna för vanliga Git-alias genom att experimentera med alternativ för Git självt (redan det en funktion som de flesta användare inte känner till).

Det här är ett bra ställe att lämna dig i väntan på del två, där vi fortsätter med:

1. !icke-Git-kommandon: Mer ”bang” för pengarna.

2. Återanvända alias.

3. Pipelina åtgärden: Kedja Unix-verktyg för mer action eller galenskap.

4. Bash-funktioner för vinsten.

5. Gå över styr eftersom gränser bara kan hittas genom att överskrida dem.

6. Bonusomgång som utforskar alternativ till Git-alias.

Gå till del två!