I vores tidligere tutorials til git-versionskontrolsoftwaren lærte vi de væsentlige grundlæggende kommandoer til brug af git, som samt hvordan man arbejder med Github.com for at oprette et arkiv og skubbe vores projektkode til hjemmesiden.
Nu er det tid til at begynde at arbejde med GitHub (og git), som de skal være brugt: foretage ændringer i projektet sikkert ud til den ene side og flette dem tilbage i det originale projekt, når de først har vist sig at være korrekte. Eller i det mindste ikke katastrofale.
Nu forstår du, at git gemmer hver version af dit projekt som et øjebliksbillede af koden nøjagtigt som det var i det øjeblik, du begik det. Oprindeligt opretter en tidslinje med versioner af et projekt, når det skrider frem, så du kan rulle tilbage til en tidligere version, hvis katastrofen rammer.
Sådan git og GitHub administrerer denne tidslinje – især når mere end en person arbejder i projektet og foretager ændringer – er ved at bruge filialer. En gren er i det væsentlige et unikt sæt kodeændringer med et unikt navn. Hvert arkiv kan have en eller flere grene. Hovedgrenen – den, hvor alle ændringer til sidst bliver slået sammen igen og kaldes master. Dette er den officielle arbejdsversion af dit projekt, og den du ser, når du besøger projektlageret på github.com/yourname/projectname.
Du skal ikke rode med mesteren. Hvis du foretager ændringer i mastergrenen i et gruppeprojekt, mens andre også arbejder på det, vil dine on-the-fly ændringer krølle ud for at påvirke alle andre, og meget hurtigt vil der være sammenfletningskonflikter, gråd, klædning af tøj, og græshoppepest. Det er så alvorligt.
Hvorfor er mesteren så vigtig at ikke rode med? Et ord: mastergrenen kan implementeres. Det er din produktionskode, klar til at rulle ud i verden. Mastergrenen er beregnet til at være stabil, og det er den sociale kontrakt med open source software at aldrig nogensinde skubbe noget til at mestre, der ikke er testet, eller som bryder build. Hele grunden til, at GitHub fungerer, er, at det altid er sikkert at arbejde fra masteren.
Forgrening ud
I stedet bruger alle grene oprettet fra master til at eksperimentere, foretage redigeringer og tilføjelser og ændringer , inden de til sidst ruller den gren tilbage til mesteren, når de er godkendt og er kendt for at arbejde. Master opdateres derefter til at indeholde alle de nye ting.
For at begynde at arbejde på noget nyt i et projekt eller for at ændre eksisterende ting opretter du en gren fra den stabile masterfilial. Lad os fortsætte med at arbejde med prøveprojektet oprettet til vores tidligere vejledning, god ol ‘studious_octo_carnival. Åbn nu din version på din computer og cd i biblioteket.
Trin 1: Tag lageropgørelse.
Inden du opretter nye filialer, vil vi kontrollere, om der findes andre eksisterende filialer . Vi ved om mesteren, men hvem ved, hvad vores projektsamarbejdere kan være med, de onde aber? Så vi kan se alle eksisterende grene ved at skrive “git branch -a” i terminalen, som fortæller git, at vi vil se ALLE grene i dette projekt, også dem, der ikke findes i vores lokale arbejdsområde.
Dette returnerer output, som du ser i kodeeksemplet nedenfor. Dets udseende kan variere noget afhængigt af dit operativsystem og terminalapplikation, men informationen er i sidste ende den samme. Stjernen ved siden af “master” i den første linje i udgangen angiver, at vi er i øjeblikket på den gren. Den anden linje fortæller os, at der på vores fjerntliggende navngivne oprindelse er en enkelt gren, også kaldet master. (Husk, at vores fjernbetjening er GitHub-repoen for dette projekt).
Trin 2: Opret en ny gren
Nu hvor vi ved, hvordan vi kan se grene, lad os lave en! Husk, når vi går, at vi har vores mesterfilial, vores originale projekt. Vi skal nu oprette en ny version af projektet, en gren, til at lege med og foretage ændringer lokalt på vores computer – mens den originale version af projektet, mesteren, forbliver sikkert upåvirket deroppe på GitHub. Vi giver den nye afdeling et beskrivende navn for at minde os om, hvad vi agter at gøre, mens vi arbejder i den. I dette tilfælde bliver det en simpel “Hello World” ting, så lad os kalde det hello_octo.
For at oprette denne nye gren skal du skrive “git checkout -b branchNameHere” (så i vores tilfælde, “git checkout -b hello_octo”).
Forudsat at ingen andre allerede har lavet en gren ved navn “hello_octo”, returnerer git “Skiftet til en ny gren ‘hello_octo’.” (I det tilfælde hvor en gren med det navn allerede eksisterer, ville git fortælle os i stedet “fatalt: En gren ved navn ‘hello_octo’ eksisterer allerede.” Ingen big deal, bare git check-b igen med en ny navne variation).
Vi kan også bruge kommandoen git checkout til at skifte frem og tilbage mellem vores to grene. Skriv “git checkout branchName” for at skifte til den gren.Så “git checkout master” fører dig til master, mens “git checkout hello_octo” tager dig tilbage til hello_octo-grenen.
Hvis du forsøger at skifte til en gren, der ikke findes, såsom “git checkout hello_kitty”, vil git fortælle dig, at det er et no-go:
Hvordan ved git, hvilken gren du er i øjeblikket? Git holder altid øje med, hvad du laver, og holder en speciel markør kaldet HEAD. Ligesom nålen på et kompas altid peger mod nord, angiver HEAD altid lokal filial, du er i øjeblikket på.
(Vi kunne også have oprettet vores filial ved hjælp af git-kommandoen “git branch branchName Here”, og skift derefter til den med git checkout. Den pæne lille genvej med “-b” i “git checkout -b branchName Here” opretter begge filialen OG skifter til den. Jeg kan ikke fortælle dig, hvor mange ny-til-git-kodere, der genererer fejlmeddelelser og frustration, fordi de simpelthen ikke har husket at skifte til deres nye gren efter oprettelse af i t. Derfor holder vi os til git checkout -b, mmmkay?)
Foretag ændringer i vores arbejdende gren
Nu hvor vi har flere grene – vores arbejdende gren til at foretage ændringer på, og vores mesterfilial forbliver sikkert ubelastet – vi kan komme på arbejde. I vores scenarie skal vi bruge vores “hello_octo” -filial til at foretage og teste vores ændringer og derefter skubbe disse tilbage op til mastergrenen på GitHub.
Husk at sikre dig, at du er på din arbejdende gren, og ikke master, med god gammel git-gren -a.
Trin 3. Opret en ny tom fil med navnet “hello_octo_world”:
(Denne tomme fil er kun til demonstrationsformål, så du skal ikke bekymre dig om, at der ikke er noget filtypenavn / -type).
Da den er helt ny, højre nu findes denne fil kun i din filial. Brug kommandoen “ls” til at se den:
Husk dog, at vi er i vores arbejdende gren, hello_octo, hvor vi skabte denne nye ting. Skibsføreren ved ikke noget om nej hello_octo, fordi det er sikkert isoleret fra de viljestyrke ændringer, vi foretager her på arbejdsbranchen. Det er stadig den samme roligt uændrede mester, vi startede med:
Trin 4: Iscenesæt og forpligt vores nye fil til en fungerende gren.
Nu er det tid at iscenesætte (tilføje) og begå vores nye fil på den arbejdende gren. (Lyder velkendt?). Dette vil vedhæfte denne nye enhed til den arbejdende gren som forberedelse til til sidst at overføre den til master. Denne fil findes nu på hello_octo-grenen; som vi så ovenfor, findes den ikke i øjeblikket på mastergrenen.
På dette tidspunkt har du lige taget en øjebliksbillede af ændringer i filialen. I et virkeligt projekt er der sandsynligvis flere ændringer og arbejde gøres. Det er nu, når du går og gør dette og laver forpligtelser undervejs på logiske punkter. Husk, at på GitHub repræsenterer forpligtelser dine fortløbende gemninger. Hver forpligtelse har en tilknyttet meddelelse, som er en beskrivelse, der specifikt forklarer, hvad du gjorde der, og hvorfor. Forpligtelsesmeddelelser registrerer historikken for dine ændringer, så fremtidige dig såvel som andre projektbidragere kan forstå, hvad du har gjort, og hvorfor.
Fletning af kode mellem grene
Når vi er endelig færdig med alle ændringer og tilføjelser – og alt fungerer * – det er tid til at flette. Den interessante del kommer efter vi skifter tilbage til vores mastergren (som – sig det med mig! – vi gør med “git checkout master”). “Hello_octo_world” ser ud til at mangle, men det er det ikke – i øjeblikket findes det på vores arbejde gren, og vi er på vores mestergren. Jeg viser dig dette igen, fordi det er kernen i at forstå grene i git:
Nu: i denne øvelse , “hello_octo_world” repræsenterer enhver ændring i enhver fil (eller tilføjelsen af en helt ny fil), der har bestået al test på vores udviklingsgren og er klar til at være i produktion. Processen med at flytte kode mellem grene (ofte fra udvikling til produktion) kaldes fusion.
Meget vigtigt: Når vi fusionerer, skal vi være på den gren, som vi vil fusionere til. Grundlæggende vil vi fortælle git, “Ser du den nye ting? Det er ok at bringe det herover nu. ”
Trin 5: Flette arbejdsgren ændringer
I dette tilfælde, da vi ønsker at fusionere fra vores arbejdsgren, hvor” hello_octo_world ” filen findes, til vores hovedfilial skal vi være på masteren.
Når vi først er på mastergrenen, skal vi køre fletningskommandoen. Den bedste måde at gøre dette på er at skrive ” git merge –no-ff ”- den ekstra” –no-ff ”fortæller git, at vi vil beholde alle de meddelelser, der er begået inden fusionen. Dette gør det nemmere at spore ændringer i fremtiden:
Kom tilbage til GitHub
Den sidste ting, vi nu skal gøre, er at lade GitHub vide, at vi har abet rundt med mestre her nede på vores lokale udviklingsmiljø.
Med andre ord er det tid til git-push. Du har dette!
Git-output bekræfter, at fletningen fra din udviklingsgren til hovedgrenen i dit lokale miljø, er nu blevet kopieret til fjernserveren: “master → master.”
Og det er det! Vi oprettede med succes en fungerende gren adskilt fra master. Foretagte ændringer i den. Iscenesat og begået disse ændringer. Så flettede dem tilbage til mesteren i vores lokale arbejdsmiljø. Derefter skubbede alt til sidst op til GitHub, så alle versioner af vores projekt er ens, overalt!
En sidste note
Noget oprydning er i orden nu: da vi har sammenlagt vores hello_octo-gren, har vi ikke længere brug for det. For at slette en flettet gren skal du blot skrive “git branch -d branchName”:
Ingen bekymringer: hvis du ved et uheld forsøger at slette en gren, der endnu ikke er blevet slået sammen, kaster git en fejl.
Så! Indtil videre har vi brugt et ekstremt forenklet eksempelprojekt, for på dette tidspunkt er det vigtigste at forstå og assimilere git-workflowet. Der er meget mere at flette end dette i den virkelige verden – for eksempel hvad sker der, hvis du får fejlmeddelelser, fordi din fusion har konflikter? Ingen bekymringer, nyt git-ster, vi kommer derhen.
Dit hjemmearbejde: Opret (“touch”) nogle flere nye filer i eksempelprojektet, og øv dig i at foretage ændringer, iscenesættelse, begåelse og endelig fletning af dem tilbage. Vær omhyggelig med at forstå, hvor dit HOVED peger – dvs. hvad din nuværende gren er. Foretag kun ændringer i din arbejdende gren.
Fordi husk: Undlad at røre. Med. .