I våre tidligere veiledninger for git versjonskontrollprogramvare lærte vi de grunnleggende grunnleggende kommandoene for bruk av git, som samt hvordan du samarbeider med Github.com for å opprette et depot og skyve prosjektkoden vår til nettstedet.
Nå er det på tide å begynne å jobbe med GitHub (og git) slik de er ment å være brukt: å gjøre endringer i prosjektet trygt til den ene siden, og slå dem sammen i det opprinnelige prosjektet når de har vist seg å være korrekte. Eller i det minste ikke katastrofale.
Nå forstår du at git lagrer hver versjon av prosjektet ditt som et øyeblikksbilde av koden akkurat som den var i det øyeblikket du begikk den. I hovedsak oppretter du en tidslinje for versjoner av et prosjekt etter hvert som det utvikler seg, slik at du kan rulle tilbake til en tidligere versjon i tilfelle katastrofe oppstår.
Slik git, og GitHub, administrerer denne tidslinjen – spesielt når mer enn en person jobber i prosjektet og gjør endringer – er ved å bruke filialer. En gren er egentlig et unikt sett med kodeendringer med et unikt navn. Hvert depot kan ha en eller flere grener. Hovedgrenen – den der alle endringer til slutt blir slått sammen igjen, og kalles mester. Dette er den offisielle arbeidsversjonen av prosjektet ditt, og den du ser når du besøker prosjektregisteret på github.com/yourname/projectname.
Ikke rot med mesteren. Hvis du gjør endringer i mastergrenen til et gruppeprosjekt mens andre også jobber med det, vil endringene dine raskt flytte ut for å påvirke alle andre, og veldig raskt vil det være sammenslåtte konflikter, gråt, kledning, og gresshoppepest. Det er så alvorlig.
Hvorfor er mesteren så viktig å ikke rote med? Ett ord: hovedgrenen kan distribueres. Det er din produksjonskode, klar til å rulle ut i verden. Hovedgrenen er ment å være stabil, og det er den sosiale kontrakten med åpen kildekode-programvare å aldri, aldri presse noe for å mestre som ikke er testet, eller som bryter bygningen. Hele grunnen til at GitHub fungerer, er at det alltid er trygt å jobbe fra mesteren.
Forgrening
I stedet bruker alle grener opprettet fra master for å eksperimentere, gjøre endringer og tillegg og endringer , før de til slutt ruller den grenen tilbake til mesteren når de er godkjent og er kjent for å fungere. Master blir deretter oppdatert for å inneholde alle de nye tingene.
For å begynne å jobbe med noe nytt i et prosjekt, eller for å endre eksisterende ting, oppretter du en gren fra den stabile mastergrenen. La oss fortsette å jobbe med prøveprosjektet som ble opprettet for vår forrige opplæring, god ol ‘studious_octo_carnival. Vennligst åpne nå versjonen din på datamaskinen din og cd-en i katalogen.
Trinn 1: Ta oversikt.
Før vi oppretter nye filialer, vil vi sjekke om det finnes andre eksisterende filialer. . Vi vet om mesteren, men hvem vet hva våre samarbeidspartnere kan ha med å gjøre, de rampete apene? Så vi kan se alle eksisterende grener ved å skrive «git branch -a» i terminalen, som forteller git at vi vil se ALLE grenene i dette prosjektet, til og med de som ikke er i vårt lokale arbeidsområde.
Dette returnerer utdataene du ser i kodeeksemplet nedenfor. Utseendet kan variere noe avhengig av operativsystem og terminalapplikasjon, men informasjonen er til slutt den samme. Stjernen ved siden av «master» i første linje i utgangen indikerer at vi er for tiden på den grenen. Den andre linjen forteller oss at på vår fjerntliggende, navngitte opprinnelse, er det en enkelt gren, også kalt master. (Husk at fjernkontrollen vår er GitHub-repoen for dette prosjektet).
Trinn 2: Opprett en ny gren
Nå som vi vet hvordan vi kan se grener, la oss lage en! Husk når vi går at vi har vår hovedfilial, vårt originale prosjekt. Vi skal nå lage en ny versjon av prosjektet, en gren, for å leke med og gjøre endringer lokalt på datamaskinen vår – mens den opprinnelige versjonen av prosjektet, mesteren, forblir trygt ulempet der oppe på GitHub. Vi gir den nye avdelingen et beskrivende navn for å minne oss på hva vi har tenkt å gjøre mens vi jobber i den. I dette tilfellet blir det en enkel «Hello World» -ting, så la oss kalle det hello_octo.
For å opprette denne nye grenen, skriv «git checkout -b branchNameHere» (så, i vårt tilfelle, «git checkout -b hello_octo»).
Forutsatt at ingen andre allerede har laget en gren med navnet «hello_octo», returnerer git «Byttet til en ny gren» hello_octo «.» (I tilfelle der en gren med det navnet allerede eksisterer, ville git fortelle oss i stedet «dødelig: En gren med navnet» hallo_octo «eksisterer allerede.» Ikke noe greit, bare gjør git-kassen -b igjen med en ny navnevariasjon).
Vi kan også bruke kommandoen git checkout til å veksle frem og tilbake mellom våre to grener. Skriv «git checkout branchName» for å bytte til den grenen.Så, «git checkout master» tar deg til å mestre mens «git checkout hello_octo» tar deg tilbake til hello_octo-grenen.
Hvis du prøver å bytte til en gren som ikke eksisterer, for eksempel «git checkout hello_kitty», vil git gi deg beskjed om at det er en no-go:
Hvordan vet git hvilken gren du befinner deg i? Git ser alltid på hva du gjør og holder en spesiell peker kalt HEAD. Som nålen på et kompass peker alltid nordover, HEAD indikerer alltid lokal filial du er for øyeblikket på.
(Vi kunne også ha opprettet vår filial ved hjelp av git-kommandoen «git branch branchName Here», og deretter bytte til den med git checkout. Imidlertid er den pene lille snarveien med «-b» i «git checkout -b branchNameHere» oppretter begge grenen OG bytter til den. Jeg kan ikke fortelle deg hvor mange ny-til-git-kodere som genererer feilmeldinger og frustrasjon fordi de rett og slett ikke har husket å bytte til sin nye gren etter å ha opprettet i t. Derfor holder vi oss til git-kassen -b, mmmkay?)
Gjør endringer i vår arbeidsgren
Nå som vi har flere grener – vår arbeidsgren å gjøre endringer på, og vår hovedfilial forblir trygt ubelastet – vi kan komme på jobb. I vårt scenario skal vi bruke vår «hello_octo» -gren for å gjøre og teste endringene våre, og deretter skyve disse tilbake til hovedgrenen på GitHub.
Husk å sørge for at du er på fungerende gren, og ikke mester, med god gammel git gren -a.
Trinn 3. Opprett en ny tom fil, kalt «hello_octo_world»:
(Denne tomme filen er bare for demonstrasjonsformål, så det er ingen grunn til bekymring for at det ikke er noe filtypenavn / type).
Siden den er helt ny, ikke sant nå er denne filen bare i din filial. Bruk kommandoen «ls» for å vise den:
Husk imidlertid at vi er på vår arbeidsgren, hallo_octo, hvor Vi skapte denne nye tingen. Mesteren vet ingenting om ingen hallo_octo, fordi den er trygt isolert fra alle villige endringer vi gjør her på arbeidsgrenen. Det er fortsatt den samme uforandret mesteren som vi startet med:
Trinn 4: Sett opp og bruk vår nye fil til en fungerende gren.
Nå er det på tide å iscenesette (legge til) og begå vår nye fil på arbeidsgrenen. (høres kjent ut?). Dette vil feste denne nye enheten til arbeidsgrenen som forberedelse til å til slutt flytte den til master. Denne filen eksisterer nå på hello_octo-grenen; som vi så ovenfor, eksisterer den foreløpig ikke på hovedgrenen.
På dette punktet har du nettopp tatt en øyeblikksbilde av endringer i grenen. I et virkelig prosjekt er det sannsynlig flere endringer og arbeid skal gjøres. Det er nå du vil gjøre dette og gjøre forpliktelser underveis på logiske punkter. Husk at på GitHub representerer forpliktelser dine påfølgende lagringer. Hver forpliktelse har en tilhørende forpliktelsesmelding, som er en beskrivelse som forklarer spesifikt hva du gjorde der og hvorfor. Forpliktende meldinger fanger historien til endringene dine, så fremtiden vil du, så vel som andre prosjektbidragsytere, forstå hva du har gjort og hvorfor.
Slå sammen kode mellom grener
Når vi er endelig ferdig med alle endringer og tillegg – og alt fungerer * – det er på tide å slå seg sammen. Den interessante delen kommer etter at vi bytter tilbake til mastergrenen vår (som – si det med meg! – vi gjør med «git checkout master»). «Hello_octo_world» ser ut til å mangle, men det er det ikke – for øyeblikket eksisterer det på vårt arbeid gren og vi er på vår mestergren. Jeg viser deg dette igjen fordi det er kjernen i å forstå grener i git:
Nå: i denne øvelsen , «hello_octo_world» representerer enhver endring i en hvilken som helst fil (eller tillegg av en helt ny fil) som har bestått all testing på vår utviklingsgren, og er klar til å være i produksjon. Prosessen med å flytte kode mellom grener (ofte fra utvikling til produksjon) er kjent som sammenslåing.
Veldig viktig: når vi slår sammen, må vi være på grenen vi vil slå sammen med. I utgangspunktet vil vi si git, «Ser du den nye tingen? Det er greit å bringe det hit nå. ”
Trinn 5: Slå sammen arbeidsgrenendringer
I dette tilfellet, siden vi ønsker å slå sammen fra vår arbeidsgren, der» hello_octo_world » filen eksisterer, til vår hovedgren må vi være på masteren.
Når vi først er på hovedgrenen, er alt vi trenger å gjøre å kjøre flettekommandoen. Den beste måten å gjøre dette på er å skrive » git merge –no-ff ”- det ekstra“ –no-ff ”forteller git at vi vil beholde alle kommisjonsmeldingene før sammenslåingen. Dette vil gjøre sporing av endringer lettere i fremtiden:
Komme tilbake til GitHub
Det siste vi nå trenger å gjøre er å fortelle GitHub at vi har apet rundt med mestre her nede på vårt lokale utviklingsmiljø.
Med andre ord er det tid for git-push. Du har dette!
Git-utdataene bekrefter at sammenslåingen fra utviklingsgrenen din til hovedgrenen i ditt lokale miljø, er nå kopiert til den eksterne serveren: «master → master.»
Og det er det! Vi opprettet en fungerende gren separat fra master. Gjorde endringer i den. Iscenesatt og forpliktet disse endringene. Slå dem sammen tilbake til master på vårt lokale arbeidsmiljø. Så til slutt, presset alt opp til GitHub slik at alle versjoner av prosjektet vårt er like, overalt!
En siste merknad
Noe opprydding er i orden nå: siden vi har slått sammen hello_octo-grenen vår, trenger vi ikke lenger den. For å slette en sammenslått gren, skriv bare «git branch -d branchName»:
Ingen bekymringer: hvis du ved et uhell prøver å slette en gren som ennå ikke er slått sammen, vil git kaste en feil.
Så! Så langt har vi brukt et ekstremt forenklet prøveprosjekt, for på dette tidspunktet er det viktigste å forstå og assimilere git-arbeidsflyten. Det er mye mer å slå sammen enn dette i den virkelige verden – for eksempel, hva skjer hvis du får feilmeldinger fordi sammenslåingen din har konflikter? Ingen bekymringer, ny git-ster, vi kommer dit.
Leksene dine: lag («berør») noen flere nye filer i eksempelprosjektet og øv deg på å gjøre endringer, iscenesette, begå og til slutt slå sammen dem tilbake. Pass på å forstå hvor HODET ditt peker – dvs. hva din nåværende gren er. Forplikt bare endringer i din arbeidsgren.
Fordi, husk: Ikke gjør det. Mess. Med. .