Hur man utför en ”Git Delete” på en lokal gren

Git är ett fantastiskt sätt att implementera versionskontroll i ett kodningsprojekt – så fantastiskt att det nästan är ett obligatoriskt alternativ.

Tanken är att skapa dubbla grenar av ditt huvudarkiv, arbeta med koden och sedan slå ihop ändringarna med resten. Detta innebär exempelvis att du kommer att ha många gamla grenar i ditt arkiv. Filstorleken på dessa ofta är liten. Du bör dock ändå utföra en git delete på en lokal gren för att hålla ordning på saker och ting.

Den goda nyheten är att detta inte kräver så mycket ansträngning. Du måste dock överväga det bästa tillvägagångssättet beroende på om du slår ihop ändringarna. Överväg dessutom vad du ska göra om du möter ett fel under raderingsprocessen. Du kan även behöva återställa en gren som du raderar. Var och en av dessa scenarier kräver olika färdigheter och kommandon.

I den här handledningen visar vi hur du utför en ”git delete” på en lokal gren. Först ska vi dock prata om några av anledningarna till att du kan vilja radera lokala grenar i Git.

Vad är en Git-gren?

Git-arkiv är en samling grenar – dubbletter av kärnkoden i dem. Faktum är att du inte kan ha ett fungerande Git-arkiv utan en gren.

Ofta har du ett primärt arkiv (de nominella namnen är ”main” och ”trunk”). Detta arkiv kommer att innehålla fungerande produktionskod som du inte vill redigera. Skapa istället en duplikatgren av huvud-arkivet och utför sedan de ändringar som du behöver inom din gren. När det är dags att föra tillbaka dessa ändringar till huvudkoden kontrollerar och sammanfogar du dem.

Med grenar kan alla i ett team samarbeta på samma projekt, oberoende av varandra. Det finns inte heller någon risk att göra en ändring i arbetskoden eller att inkräkta på andra ändringar under tiden.

Du måste dock även utföra en git delete på en lokal gren. Detta kommer att vara en regelbunden åtgärd för dig, och det finns ett antal goda skäl till att göra detta.

Varför ska man ta bort grenar i Git?

Din produktionskod kommer att finnas i huvudgrenen. Detta är den enda gren som har en viss permanens.

Däremot kommer nästan alla andra grenar som du skapar att ha en tillfällig hållbarhet. När du har slutfört ditt arbete kommer du att lägga in ändringarna. Du kan sedan slå samman dem med huvudgrenen, eventuellt i ett online-arkiv som GitHub.

Detta innebär exempelvis att du ofta har många grenar öppna samtidigt, beroende på projektet och teamet. När du väl har slutfört sammanslagningen försvinner dock inte dessa grenar.

Det finns därför några skäl till varför du bör ta bort en lokal Git-gren:

• Allmänt hushållsarbete: När du lagar mat hemma tvättar du redskapen och lägger undan dem. Samma sak gäller när du arbetar med ett Git-arkiv: När du är klar med ditt arbete slår du ihop ändringarna och raderar grenar som du inte längre behöver. Detta gör dessutom ditt projekt och ditt arkiv lättare att navigera i.
• Storlek på filstorlek för arkiv: Git-arkiv är ofta tillräckligt små för att sakna betydelse för projektets storlek. Du bör dock ändå hålla ett öga på det. Ett sätt att minska storleken på ett arkiv är att ta bort grenar som du inte behöver.
• Potentiell prestanda: Även om din kärnkod är prestandaklassad kan det hända att en gren inte är detta. Särskilt med tanke på att du arbetar med den. På grund av detta bör du hålla öppna grenar till ett minimum. Annars kan detta introducera dålig prestanda för ditt team tills du stegvis anpassar och justerar ett projekt.

Som du kommer att se senare är det väldigt enkelt att utföra en git delete på en lokal gren. Det är dock en bra idé att förstå vad som händer under huven när det gäller att använda det här kommandot. Det raderar nämligen inte allt som rör grenen från ditt arkiv.

Vad händer när du tar bort en lokal Git-gren?

På en teknisk nivå är en gren bara en pekare mot ett specifikt utförande – en sektion av koden som du vill inkludera i din huvudgren. På grund av detta kommer utföranden att finnas kvar när du raderar en lokal Git-gren.

Senare kommer vi att prata om gren-återställning och vad som är möjligt tack vare att dessa utföranden finns kvar i ditt arkiv. För tillfället räcker det dock att du förstår att det finns två olika typer av ändringar:

• Sammanfogade ändringar: När du slår ihop en gren med huvudgrenen kommer koden att vara så uppdaterad som möjligt. I tekniska termer är detta liktydigt med att flytta huvudgrenens referens för att komma ikapp din sekundära gren.
• Ändringar som inte har sammanfogats: Om du inte slår ihop ändringar kommer du att ha en gren som inte är lika uppdaterad som huvudgrenen. Huvudgrenen kommer därför inte att ha ett uppdaterat referens-utförande.

Detta är något som vi kommer att prata mer ingående om senare. Det leder oss dock fram till en annan bra punkt om när man ska ta bort grenar.

När du ska utföra en ”Git Delete” på en lokal gren

Det finns många faror med att radera en gren med icke-sammanfogade ändringar. Av den anledningen är det viktigt att inte köra en git delete på en lokal gren förrän du utför en kodfusion. Detta kommer exempelvis att säkerställa att varje gren har en uppdaterad referens, och i förlängningen den mest aktuella koden som finns tillgänglig.

Det är dessutom en bra idé att se till att du inte kommer att behöva någon av de ändringar som finns i en tillfällig gren innan du utför en git delete. Du kan visserligen återställa grenar i viss utsträckning. Detta är dock ett arbete som du helst bör undvika. Vi kommer att ge dig en inblick i detta senare.

Hur man utför en ”Git Delete” på en lokal gren

Under resten av den här handledningen kommer vi att visa dig hur du utför en git delete på en lokal gren. Vi kommer sedan att prata om vad vi ska göra med icke-sammanfogade ändringar.

Därefter pratar vi om fel som du kan möta, och sedan om hur du återställer en raderad lokal gren.

I slutet tar vi en kort titt på fjärrgrenar och hur man raderar dem.

Förutsättningar

Git erbjuder en enkel uppsättning kommandon direkt ur låtan. Som ett resultat får du mycket kraft utan att du behöver slå upp en lärobok. Trots detta finns det några olika sätt att komma åt ett Git-arkiv beroende på vilken app och kodredigerare som du väljer.

Du skulle visserligen kunna hitta en ”minimal klick”-uppsättning i ett dedikerat grafiskt användargränssnitt (GUI) som GitKraken eller Sublime Merge. Vi kommer dock att hålla det enkelt och använda verktyg som är inbyggda i operativsystemet.

För att följa med behöver du följande:

• Tillgång till kommandoraden: Våra exempel kommer att använda macOS och iTerm. Du kan dock använda Cmder för Windows, standardterminalen i macOS, samma terminal i Linux, med mera.
• Tillgång till dina specifika filer: Du bör ha dina projektfiler på din lokala dator, för utan dem finns det inget som du kan göra!
• Kunskap om kommandoraden: Det hjälper att ha en viss kunskap om kommandoraden – särskilt kommandon som hjälper dig att navigera i dina filer. Utöver detta så bör du ha en viss förståelse för hur kommandoraden fungerar.

I verkligheten är detta allt som du behöver om du har ett projekt med ett Git-arkiv och ett valfritt Terminalfönster.

Utföra en grundläggande ”Git Delete”

Först och främst antar vi att du vill ta bort en gren med sammanslagna ändringar. Detta är den mest okomplicerade och typiska metoden.

Du kan dock först behöva köra git branch -a eller git branch --list för att visa alla grenar och hitta rätt gren i ditt arkiv:

Här är kommandot som du behöver för att ta bort en gren:

git branch -d branch-name

Du bör använda det specifika grennamnet i stället för vår platshållare.

Flaggan -d står här för ”delete” (radera), och med små bokstäver har du ett visst skydd mot att radera en gren med obearbetade ändringar.

Om du försöker att ta bort en icke-sammanslagen gren får du ett felmeddelande (egentligen mer en varning):

Du kan dock skriva flaggan med stor bokstavsbeteckning med -D och hoppa över denna skyddande varning. Som ett resultat kan du ta bort en gren med ändringar som inte har sammanfogats.

Observera att du inte får en bekräftelse på att du kan ta bort grenen om du använder den versala versionen. Detta är med andra ord en flagga som du bör använda med försiktighet.

Vad orsakar felet ”Cannot Delete Branch”?

Eftersom radering av en gren i ditt arkiv är ett stort beslut utan en enkel lösning, skickar Git felmeddelanden om du gör fel.

Du kommer exempelvis ibland att vilja utföra en git delete på en lokal gren och se ett ”Cannot delete branch”-fel:

Den enkla orsaken ligger i din nuvarande plats i Git-arkivet. Du kan inte radera en gren som du ”checkar ut”.

Lösningen här är att flytta till en annan gren.

Av den här anledningen föreslår vi alltid att du checkar ut till main-grenen. Som ett resultat möter du ett felmeddelande om du försöker ta bort main, och du kan dessutom rensa ut alla andra grenar i arkivet.

Så här återställer du en raderad lokal Git-gren

Ett utförande kommer att finnas kvar efter att du har raderat en lokal gren. Det finns därför en liten möjlighet att återställa en gren efter att du har utfört en git delete. Det är dock mer besvärligt än att slå samman dessa ändringar först. I den situationen vet du att du inte längre behöver en gren.

Varje utförande använder ett hashnummer som fungerar som dess referens. Du kan använda detta hashnumret för att checka ut och skapa en ny gren:

Men om du inte känner till hashkoden för en raderad gren kan du använda kommandot reflog. Dessa ”referens-hashar” är mycket lika de som du hittar i appar som DevKinsta.

Även om användningen av git reflog är ett samtal för en helt annan artikel, kan du använda grundläggande funktioner för att hitta hashen för gamla utföranden. Om du kör git reflog får du en lista över utföranden:

Den första kolumnen med hash-koder här låter dig sedan checka ut utförandet och skapa en ny gren. Exempelvis:

git checkout 5744ff6

git branch f9d2db5

Detta är dock inte ett idiotsäkert sätt att återställa en raderad gren i Git.

I vissa fall kommer det inte att finnas något utförande i refloggen, och ingen HEAD-referens till själva utförandet. Det är därför bättre att arbeta med dina grenar på ett säkrare sätt genom att slå ihop ändringar innan du utför en git delete på en lokal gren.

Arbeta med fjärrstyrda Git-grenar

När du utför en git delete på en lokal gren har du ofta ett associerat fjärr-arkiv. Detta gäller särskilt om du drar ner din webbplats till Kinsta med hjälp av Git.

Detta arkiv kommer inte att uppdateras tillsammans med ditt lokala arkiv när du gör ändringar. samma sak gäller när du tar bort en lokal gren.
Både GitHub och GitLab har dock samma process för att ta bort en fjärr Git-gren. Det är ett liknande tillvägagångssätt som alla andra flyttningar ”uppströms”.

Här är kommandot:

git push remote-name -d remote-branch

För remote-name använder de flesta arkiv som vi ser ”ursprungs”-referensen remote-branch. Den kommer att vara densamma som den lokala grenen (om du inte byter namn på en lokal gren, vilket ligger utanför den här artikelns räckvidd).

Som ett sidospår kan du se alla grenar – både lokala och fjärrbaserade – med hjälp av git branch -a. Om du endast vill se fjärrgrenar kan du använda git branch -r.

När du har kört kommandot får du ett bekräftelsemeddelande. Du bör då köra git branch -a igen för att kontrollera att allt har tagits bort på det sätt som du förväntar dig.

Sammanfattning

Git är ett av få verktyg som ger dig en enorm kraft under huven med hjälp av lättlästa och intuitiva kommandon. Detta gäller även för att ta bort grenar som du inte längre behöver på din lokala maskin. Du måste dock fortfarande se till att köra en git delete på en lokal gren.

Om du försöker ta bort ändringar som inte har lagts ner kommer du nämligen antingen att få ett fel eller ta bort något som kommer att påverka ditt framtida projektarbete. Dessutom måste du även radera den fjärrbaserade grenen. Både ditt lokala arkiv och fjärr-arkiv behöver du utföra en god hushållning för att hålla prestandan hög och filstorleken minimal.

Man kan känna verkligen känna sig ensam om man raderar en Git-gren av misstag. Kinsta kan dock hjälpa dig när det gäller Applikationshosting. Vår hosting-plattform ger dig möjlighet att ansluta till och distribuera med dina GitHub-arkiv på bara några minuter. Dessutom får du tillgång till Google’s C2-maskiner och Premiumnivånätverk, tillsammans med vår Cloudflare-integrering, för att driva dina appar till nästa nivå av hastighet och säkerhet.