Om du skriver programvara för att leva under 2018, kan jag med säkerhet säga att du känner till Git. verktyget skapat av Linus Torvalds har blivit synonymt med versionskontroll. Utan tvekan är en av Gits bästa funktioner hur det tar bort smärtan vid förgrening och sammanslagning. Det finns flera sätt att skapa en filial i Git. I det här inlägget kommer vi att granska några av dem. Då slutar vi med lite reflektion över Gits förgreningsmodell och förgrening i allmänhet.

Skapa en gren från mästare

Du skapar filialer i Git, inte förvånande, genom att använda filialkommandot. Liksom många andra Git-kommandon är ”gren” mycket kraftfull och flexibel. Förutom att skapa filialer kan den också användas för att lista och ta bort dem, och du kan ytterligare anpassa kommandot genom att använda en bred lista med parametrar. Vi börjar med det första sättet att skapa en filial. Låt oss säga att du vill skapa en ny mapp som heter ”min-app”, ange den och starta ett nytt Git-arkiv. Det är precis hur du skulle göra det:

mkdir my-appcd my-appgit init

Nu har du ett nytt, tomt Git-arkiv. Men tomma arkiv är tråkiga. Så vad sägs om att skapa en ny markdown-fil med ”Hello World!” skriven i den?

echo Hello World! > file.md

Om du kör ”git status”, bör du se ett meddelande som säger att din fil inte är spårad:

Ospårade filer är dock också svala, så låt oss spåra det:

git add file.md

Och slutligen, låt oss skapa våra första engagemang:

git commit -m "First commit"

Vi har nu ett arkiv med en gren, som har exakt ett engagemang. Det kanske inte låter som det mest spännande i världen (för att det verkligen inte är det), men det är verkligen mindre tråkigt än att ha en repo utan några åtaganden alls, eller hur? Låt oss säga att av någon anledning behöver du ändra filen ”innehåll. Men du behöver inte känner för att göra det. Vad händer om något går fel och du på något sätt förstör det vackra, orörda innehållet i din fil? (Ja, jag vet att det bara är en dum fil med ”Hello World!” I den, men använd din fantasis underbara krafter och tänk på filen som en proxy för ett mycket mer komplext projekt.) Lösningen på detta dilemma skapar naturligtvis en ny gren:

git branch exp

Så nu har vi en ny gren som heter ”exp”, för experiment Vissa människor som är vana vid att använda olika versioneringssystem, särskilt centraliserade, kan säga att filialerna har samma ”innehåll”. Detta är dock inte helt korrekt när man pratar om Git. Tänk på grenar som referenser som pekar på ett visst engagemang.

Skapa en gren från ett åtagande

Antag att vi, oavsett anledning, ger upp vårt experiment utan att lägga till en enda förbinda sig till den nya filialen. Låt oss gå tillbaka till mastern och ta bort exp-grenen:

git checkout mastergit branch -d exp

Nu när vi är tillbaka till en enda gren, låt oss lägga till några åtaganden för att simulera det arbete som utförs:

Tänk dig att efter att ha gjort allt detta ”arbete” lär du dig att du, oavsett anledning, måste gå tillbaka i tiden till när det finns var bara två rader i filen och skapade nya ändringar därefter. Men samtidigt måste du bevara de framsteg du redan gjort. Med andra ord vill du skapa en gren från ett tidigare åtagande. Hur skulle du göra det ? I Git har varje engagemang en unik identifierare. Så du kan enkelt se detta med kommandot ”git log”. För att skapa en ny gren baserad på ett specifikt engagemang, skicka bara dess hash som parameter till grenkommandot:

git branch new-branch 7e4decb

Som bortom behöver du inte ens hela hashen för det mesta. Bara de första fem eller sex tecknen gör det.

Skapa en gren från en tagg

Om du är lite mer erfaren med Git, bör du känna till begreppet taggar. Du använder taggar för att indikera att ett visst engagemang är viktigt eller speciellt på något sätt. Till exempel används taggar vanligtvis för att indikera de faktiska versionerna av en produkt. Om du har arbetat i din applikation ett tag och du tror att det är dags att släppa version 1.0, vad du vanligtvis gör är att stöta på versionsnumren när det är nödvändigt, begå ändringarna och sedan lägga till en tagg till den specifika tidpunkten. För att skapa en tagg kör du vanligtvis något så här:

git tag -a v1.0 -m "First major version"

Parametern ”-a” indikerar att detta går att vara en antecknad tagg. I motsats till en lättviktsetikett är detta ett fullblåst Git-objekt som innehåller bitar av information som uppdragsgivarens namn och e-post, tidsstämpel och ett meddelande. Nu har du en tagg, en indikation på att just denna punkt i historien är speciell och har ett namn. Trevlig. Du kan fortsätta att arbeta, som vanligt, skapa och göra ändringar som kommer att ingå i 1.1-versionen. Tills en felrapport kommer in. Vissa klienter som uppdaterades till 1.0-versionen av produkten säger att en importfunktion inte fungerar som avsett. Tja, du kan teoretiskt fixa felet i huvudgrenen och distribuera det. Men då skulle klienterna få funktioner som är potentiellt oproverade och ofullständiga. Det ”sa nej -Nej. Så vad gör du? Svaret: Du skapar en ny gren från taggen du har skapat för att ange huvudversionen. Du åtgärdar problemet där, bygger och distribuerar. Och du borde förmodligen slå samman detta till master efteråt, så nästa versioner innehåller fixen Hur skulle du göra det? Enkelt:

git branch <NAME-OF-THE-BRANCH> <TAG>

Mer specifikt med vårt tidigare exempel:

git branch fix-bug-123 v1.0

Därefter kan du kolla in din nya filial som vanligt. Eller ännu bättre, du kan göra allt i ett steg:

git checkout -b fix-bug-1234 v1.0

Skapa en filial i fristående huvudstat

Har du någonsin velat gå tillbaka i tiden? Med Git är detta möjligt … åtminstone när det gäller filerna i vårt arkiv. Du kan när som helst kolla in ett engagemang om du känner till dess hash:

git checkout <SHA1>

Efter att ha kört det kommer Git att visa dig ett nyfiket meddelande:

You are in "detached HEAD" state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

När du checkar ut ett engagemang, du går in i ett speciellt tillstånd c alled, som du kan se, ”fristående HEAD”. Även om du kan begå ändringar i detta tillstånd tillhör dessa åtaganden inte någon gren och kommer att bli oåtkomliga så fort du checkar ut en annan gren. Men vad händer om du vill behålla dessa åtaganden? Svaret är inte förvånande att använda kommandot ”kassan” igen för att skapa en ny gren:

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

Och naturligtvis vet du nu att du kan skriva de två sista raderna som ett enda kommando:

git checkout -b new-branch-to-keep-commits

Ganska enkelt, eller hur?

Bara för att du kan … Betyder inte att du borde

Gits förgreningsmodell är en av dess försäljningsställen. Det förvandlar det som i andra källkontrollsystem är en smärtsam och till och med långsam process till en vind. Man kan säga att Git framgångsrikt har demokratiserat förgrening för massorna. Men det finns en allvarlig fara. På grund av det billiga med att förgrena sig i Git kan vissa utvecklare falla i fällan att arbeta med extremt långlivade filialer eller använda arbetsflöden eller förgreningsmodeller som fördröjer inte gration. Vi som bransch har varit där. Vi har gjort det. Det fungerar inte. Omfatta istället arbetsflöden som använder extremt kortlivade filialer. Du kommer att ha en säker sandlåda där du kan koda utan rädsla för att bryta ner saker eller slösa bort dina medarbetares tid. Men frågar du, ”Hur distribuerar jag kod med delvis slutförda funktioner?” I så fall finns det flaggor till undsättning. Git-grenar är ett kraftfullt verktyg. Använd dem klokt och missbruk dem inte. Och när de inte räcker, använd kontinuerlig leverans / kontinuerlig integration tillsammans med funktionsflaggor – inklusive specialverktyg till ditt förfogande – så att dina applikationer kan komma till nästa nivå.