Denne siden er en undersøkelse av git checkout -kommandoen. Det vil dekke brukseksempler og kantsaker. I Git-termer er en «kassa» handlingen med å bytte mellom forskjellige versjoner av en målenhet. Kommandoen git checkout opererer på tre forskjellige enheter: filer, forpliktelser og grener. I tillegg til definisjonen av «kassa» brukes uttrykket «utsjekking» ofte for å antyde handlingen med å utføre git checkout -kommandoen. I emnet Angre endringer så vi hvordan git checkout kan brukes til å se gamle forpliktelser. Fokus for flertallet av dette dokumentet vil være kasseoperasjoner på filialer.

Utsjekking av grener ligner på å sjekke ut gamle forpliktelser og filer ved at arbeidskatalogen er oppdatert for å matche den valgte grenen / revisjonen; imidlertid blir nye endringer lagret i prosjektloggen – det vil si at det ikke er en skrivebeskyttet operasjon.

Sjekke ut grener

git checkout kommando lar deg navigere mellom grenene opprettet av git branch. Når du sjekker ut en gren, oppdateres filene i arbeidskatalogen slik at de samsvarer med versjonen som er lagret i den grenen, og den forteller Git å registrere alle nye forpliktelser på den grenen. Tenk på det som en måte å velge hvilken utviklingslinje du jobber med.

Å ha en egen filial for hver nye funksjon er et dramatisk skifte fra en tradisjonell SVN-arbeidsflyt. Det gjør det latterlig enkelt å prøve nye eksperimenter uten frykt for å ødelegge eksisterende funksjonalitet, og det gjør det mulig å jobbe med mange ikke-relaterte funksjoner samtidig. I tillegg tilrettelegger filialer også for flere samarbeidsflyter.

Kommandoen git checkout kan av og til forveksles med git clone. Forskjellen mellom de to kommandoene er at klon fungerer for å hente kode fra et eksternt lager, alternativt fungerer kassen for å bytte mellom versjoner av kode som allerede er på det lokale systemet.

Bruk: Eksisterende grener

Forutsatt at repoen du jobber i inneholder eksisterende grener, kan du bytte mellom disse grenene ved hjelp av git checkout. For å finne ut hvilke grener som er tilgjengelige og hva det nåværende grennavnet er, utfør git branch.

Eksemplet ovenfor viser hvordan du viser en liste over tilgjengelige grener ved å utføre git branch kommando, og bytt til en spesifisert gren, i dette tilfellet feature_inprogress_branch.

Nye grener

Git checkout fungerer hånd i hånd med git branch. git branch -kommandoen kan brukes til å opprette en ny gren. Når du vil starte en ny funksjon, oppretter du en ny gren av ved hjelp av git branch new_branch. Når du er opprettet, kan du bruke git checkout new_branch for å bytte til den grenen. I tillegg godtar kommandoen git checkout et -b -argument som fungerer som en praktisk metode som vil opprette den nye grenen og umiddelbart bytte til den. Du kan jobbe med flere funksjoner i et enkelt arkiv ved å bytte mellom dem med git checkout.

Eksemplet ovenfor samtidig oppretter og sjekker ut . Alternativet -b er et bekvemmelighetsflagg som forteller Git å kjøre git branch før du kjører git checkout .

Som standard git checkout -b vil basere new-branch nåværende HEAD. En valgfri tilleggsparameter kan sendes til git checkout. I eksemplet ovenfor sendes som deretter baserer new-branch av existing-branch i stedet for gjeldende HEAD.

Bytte avdelinger

Bytte av grener er en grei handling. Å utføre følgende vil peke HEAD til tuppen av .

Git sporer en historie med kasseoperasjoner i refloggen. Du kan utføre git reflog for å se historikken.

Git Checkout a Remote Branch

Når du samarbeider med et team, er det vanlig å bruke ekstern repositories. Disse arkivene kan være vert og deles, eller de kan være en annen kollegas lokale kopi. Hvert eksternt arkiv vil inneholde sitt eget sett med grener. For å kasse en ekstern gren må du først hente innholdet i grenen. >

I moderne versjoner av Git kan du deretter sjekke den eksterne grenen som en lokal gren.

Eldre versjoner av Git krever at det opprettes en ny gren basert på remote.

I tillegg kan du kasse en ny lokalfilial og tilbakestille den til de eksterne grenene sist forpliktet.

Frittliggende HEADS

Nå som vi har sett de tre viktigste bruken av git checkout på grener, er det viktig å diskutere "detached HEAD” tilstand. Husk at HEAD er Gits måte å referere til gjeldende øyeblikksbilde. Internt er git checkout kommandoen oppdaterer bare HEAD for å peke på enten den angitte grenen eller begå. Når den peker på en gren, klager ikke Git, men når du sjekker ut en commit, bytter til en "detached HEAD” -tilstand.

Dette er en advarsel som forteller deg at alt du gjør er «løsrevet» fra resten av prosjektets utvikling. Hvis du skulle begynne å utvikle en funksjon mens det i en frittliggende HEAD tilstand, ville det ikke være noen gren som lar deg komme tilbake t o det. Når du uunngåelig sjekker ut en annen gren (f.eks. For å slå sammen funksjonen din), vil det ikke være noen måte å referere til funksjonen din:

Poenget er, utviklingen din skal alltid skje på en gren – aldri på en frittliggende HEAD. Dette sørger for at du alltid har en referanse til de nye forpliktelsene dine. Men hvis du bare ser på en gammel kommisjon, spiller det ingen rolle om du er i en frittliggende HEAD -status eller ikke.

Sammendrag

Denne siden fokuserte på bruk av kommandoen git checkout når du bytter gren. I sammendrag endrer git checkout, når det brukes på grener, målet for HEAD ref. Den kan brukes til å lage grener, bytte gren og kasse eksterne grener. git checkout -kommandoen er et viktig verktøy for standard Git-drift. Det er en motstykke til git merge. Kommandoene git checkout og git merge er viktige verktøy for å aktivere git workflows.