I våra tidigare självstudier för git-versionskontrollprogramvaran lärde vi oss de grundläggande grundläggande kommandona för att använda git, som samt hur man samarbetar med Github.com för att skapa ett förvar och driva vår projektkod till webbplatsen.
Nu är det dags att börja arbeta med GitHub (och git) som de är tänkta att vara används: göra ändringar i projektet säkert till ena sidan och slå samman dem i det ursprungliga projektet när de har visat sig vara korrekta. Eller åtminstone inte katastrofalt.
Nu förstår du att git sparar varje version av ditt projekt som en ögonblicksbild av koden exakt som den var när du begick den. Skapa i huvudsak en tidslinje med versioner av ett projekt när det fortskrider, så att du kan rulla tillbaka till en tidigare version i händelse av en katastrof.
Hur git och GitHub hanterar denna tidslinje – särskilt när mer än att en person arbetar i projektet och gör ändringar – använder filialer. En gren är i huvudsak en unik uppsättning kodändringar med ett unikt namn. Varje arkiv kan ha en eller flera grenar. Huvudgrenen – den där alla förändringar så småningom slås samman igen och kallas mästare. Detta är den officiella arbetsversionen av ditt projekt och den du ser när du besöker projektförvaret på github.com/yourname/projectname.
Rör inte med befälhavaren. Om du gör ändringar i huvudgruppen för ett gruppprojekt medan andra också arbetar med det, kommer dina förändringar direkt att rippa ut för att påverka alla andra och väldigt snabbt kommer det att gå samman konflikter, gråt, klädesplagg, och gräshoppor. Det är så allvarligt.
Varför är mästaren så viktig att inte röra med? Ett ord: huvudgrenen kan distribueras. Det är din produktionskod, redo att rulla ut i världen. Mastergrenen är tänkt att vara stabil, och det är det sociala kontraktet med öppen källkodsprogramvara att aldrig, någonsin driva något för att bemästra som inte testas eller som bryter byggnaden. Hela anledningen till att GitHub fungerar är att det alltid är säkert att arbeta från mastern.
Förgrena sig
Istället använder alla grenar som skapats från master för att experimentera, göra ändringar och tillägg och ändringar , innan de så småningom rullar den grenen tillbaka in i mästaren när de har godkänts och är kända för att fungera. Master uppdateras sedan så att det innehåller alla nya saker.
För att börja arbeta med något nytt i ett projekt eller för att ändra befintliga saker skapar du en gren från den stabila huvudgrenen. Låt oss fortsätta arbeta med det exempelprojekt som skapats för vår tidigare handledning, bra ol ’studious_octo_carnival. Öppna nu din version på din dator och cd i katalogen.
Steg 1: Ta inventering.
Innan vi skapar nya filialer vill vi söka efter andra befintliga filialer . Vi vet om befälhavaren, men vem vet vad våra projektsamarbetare kan göra, de onda aporna? Så vi kan visa alla befintliga filialer genom att skriva ”git branch -a” i terminalen, vilket säger att vi vill se ALLA filialer i detta projekt, även de som inte finns i vår lokala arbetsyta.
Detta returnerar utdata som du ser i kodexemplet nedan. Dess utseende kan variera något beroende på ditt operativsystem och terminalapplikation, men informationen är i slutändan densamma. Stjärnan bredvid ”master” i utgångens första rad indikerar att vi är för närvarande på den grenen. Den andra raden berättar att på vår avlägsna, namngivna ursprung, finns en enda gren, även kallad master. (Kom ihåg att vår fjärrkontroll är GitHub repo för detta projekt).
Steg 2: Skapa en ny gren
Nu när vi vet hur vi kan se grenar, låt oss göra en! Tänk på att vi har vår huvudfilial, vårt ursprungliga projekt. Vi ska nu skapa en ny version av projektet, en filial, att leka med och göra ändringar lokalt på vår dator – medan den ursprungliga versionen av projektet, befälhavaren, förblir säkert oupplöst där uppe på GitHub. Vi ger den nya filialen ett beskrivande namn för att påminna oss om vad vi tänker göra när vi arbetar i den. I det här fallet kommer det att bli en enkel ”Hello World” -ting, så låt oss kalla det hello_octo.
För att skapa den här nya grenen, skriv ”git checkout -b branchNameHere” (så, i vårt fall, ”git checkout -b hello_octo”).
Förutsatt att ingen annan redan har skapat en filial med namnet ”hello_octo”, returnerar git ”Bytt till en ny gren” hello_octo ”.” (Om en filial med det namnet redan finns, skulle git säga oss istället ”dödlig: En gren med namnet ’hello_octo’ existerar redan.” Ingen grej, gör bara gitkassan -b igen med en ny namnvariation).
Vi kan också använda kommandot git checkout för att växla fram och tillbaka mellan våra två grenar. Skriv ”git checkout branchName” för att växla till den grenen.Så, ”git checkout master” tar dig att behärska medan ”git checkout hello_octo” tar dig tillbaka till hello_octo-grenen.
Om du försöker växla till en filial som inte finns, till exempel ”git checkout hello_kitty”, kommer git att meddela dig att det inte går:
Hur vet git vilken gren du för närvarande är på? Git tittar alltid på vad du gör och håller en speciell pekare som heter HEAD. Som nålen på en kompass pekar alltid norr, HEAD indikerar alltid lokal filial du befinner dig för närvarande.
(Vi kunde också ha skapat vår filial med hjälp av git-kommandot ”git branch branchName Here”, och sedan byta till det med git-kassan. Men den snygga lilla genvägen med ”-b” i ”git checkout -b branchNameHere” skapar båda filialen OCH växlar till den. Jag kan inte berätta hur många ny-till-git-kodare genererar felmeddelanden och frustration eftersom de helt enkelt inte har kommit ihåg att byta till sin nya gren efter att jag skapat i t. Därför håller vi fast vid git-kassan -b, mmmkay?)
Gör ändringar i vår arbetsgren
Nu när vi har flera grenar – vår arbetsgren att göra ändringar på, och vår mästare förblir säkert oönskad – vi kan komma till jobbet. I vårt scenario ska vi använda vår ”hello_octo” -gren för att göra och testa våra ändringar och sedan trycka tillbaka dem till huvudgrenen på GitHub.
Kom ihåg att se till att du är på din fungerande gren, och inte master, med bra gammal git-gren -a.
Steg 3. Skapa en ny tom fil med namnet ”hello_octo_world”:
(Den här tomma filen är bara för demonstrationsändamål, så du behöver inte oroa dig för att det inte finns något filtilläggsnamn / -typ).
Eftersom den är helt ny, höger nu finns den här filen bara i din filial. Använd kommandot ”ls” för att visa det:
Kom dock ihåg att vi är på vår arbetsgren, hello_octo, där vi skapade den här nya saken. Befälhavaren vet ingenting om inget hej_octo, för det är säkert isolerat från alla villiga förändringar vi gör här på arbetsgrenen. Det är fortfarande samma lugnt oförändrade mästare som vi började med:
Steg 4: Sätt upp och överlåta vår nya fil till en fungerande gren.
Nu är det dags att iscensätta (lägga till) och begå vår nya fil på arbetsgrenen. (låter bekant?). Detta kommer att fästa den nya enheten till arbetsgrenen för att så småningom flytta den till master. Den här filen finns nu på grenen hello_octo; som vi såg ovan finns det för närvarande inte på huvudgrenen.
Vid denna punkt har du precis tagit en ögonblicksbild av förändringar i filialen. I ett verkligt projekt finns det sannolikt fler förändringar och arbete att vara klar. Nu är det när du skulle göra detta och göra åtaganden längs vägen vid logiska punkter. Kom ihåg att på GitHub representerar åtaganden dina på varandra följande sparningar. Varje engagemang har ett associerat meddelande, vilket är en beskrivning som specifikt förklarar vad du gjorde där och varför. Kommunicera meddelanden fånga historiken för dina ändringar, så framtida kan du, liksom andra projektbidragare, förstå vad du har gjort och varför.
Sammanfoga kod mellan grenar
När vi är äntligen klar med alla ändringar och tillägg – och allt fungerar * – det är dags att gå samman. Den intressanta delen kommer efter att vi byter tillbaka till vår mästergren (som – säg det med mig! – vi gör med ”git checkout master”). ”Hello_octo_world” verkar saknas, men det är inte – för närvarande finns det på vårt arbete gren och vi är på vår mästare gren. Jag visar dig detta igen eftersom det är kärnan i att förstå grenar i git:
Nu: i den här övningen , ”hello_octo_world” representerar alla ändringar i alla filer (eller tillägg av en helt ny fil) som har klarat alla tester på vår utvecklingsgren och är redo att vara i produktion. Processen med att flytta kod mellan grenar (ofta från utveckling till produktion) kallas sammanslagning.
Mycket viktigt: när vi slår samman måste vi vara på den filial som vi vill slå ihop. I grund och botten kommer vi att säga git, ”Ser du den nya saken? Det är ok att ta med det här nu. ”
Steg 5: Sammanfoga arbetsgrenens förändringar
I det här fallet, eftersom vi vill gå samman från vår arbetsgren där” hello_octo_world ” filen finns, till vår huvudfilial måste vi vara på mastern.
En gång på huvudgrenen är allt vi behöver göra att köra kommandot Flätning. Det bästa sättet att göra detta är att skriva ” git merge –no-ff ”- tillägget” –no-ff ”berättar för git att vi vill behålla alla kommuniceringsmeddelanden före sammanslagningen. Detta kommer att göra spårningsändringarna enklare i framtiden:
Komma tillbaka till GitHub
Det sista vi nu behöver göra är att låta GitHub veta att vi har apat runt med behärska här på vår lokala utvecklingsmiljö.
Med andra ord är det dags för git-push. Du har det här!
Git-utdata bekräftar att sammanslagningen från din utvecklingsgren till huvudgrenen i din lokala miljö, har nu kopierats till fjärrservern: ”master → master.”
Och det är det! Vi har framgångsrikt skapat en fungerande gren separat från master. Gjorde ändringar i den. Iscensatt och åtagit sig dessa ändringar. Slå sedan ihop dem tillbaka till mästare på vår lokala arbetsmiljö. Sedan slutligen, tryckte allt upp till GitHub så att alla versioner av vårt projekt är desamma, överallt!
En sista anmärkning
Någon sanering är i ordning nu: eftersom vi lyckats slå samman vår hello_octo-gren behöver vi inte längre den. För att radera en sammanslagen gren, skriv bara ”git branch -d branchName”:
Inga bekymmer: om du av misstag försöker ta bort en gren som ännu inte har sammanfogats, kommer git att kasta ett fel.
Så! Hittills har vi använt ett extremt förenklat exempelprojekt, för just nu är det viktigaste att förstå och assimilera git-arbetsflödet. Det finns mycket mer att slå samman än detta i den verkliga världen – till exempel, vad händer om du får felmeddelanden eftersom din sammanslagning har konflikter? Inga bekymmer, ny git-ster, vi kommer dit.
Din läxa: skapa (”touch”) några fler nya filer i exempelprojektet och öva på att göra ändringar, iscensätta, begå och slutligen slå samman dem tillbaka. Var noga med att förstå vart ditt HEAD pekar – det vill säga vad din nuvarande gren är. Bara bara ändra din arbetsfilial.
Eftersom, kom ihåg: Gör inte. Rör. Med. .