Share
Git har blitt det mest brukte systemet for versjonskontroll og delingskode. Hvis du vil bidra til å bygge åpen programvare, eller hvis du vil jobbe på et profesjonelt team, er forståelse Git et must.
I en serie Git-kurs på Envato Tuts + forklarte jeg noen av Git-konseptene, alt illustrert med hjelpsomme animasjoner.
I denne videoen lærer du om de tre trærne: HEAD, indeksen og arbeidskatalogen. Se som jeg forklarer rollen til hver og hvordan de samhandler når du oppdaterer og forplikter kode.
For bedre å forstå hvordan Git fungerer, kan vi bruke metaforen til de tre trærne. Disse trærne er forskjellige samlinger av filer.
For arbeidsflyten av å legge til og hente begår, bruker Git tre forskjellige versjoner av filer:
Hvert av disse trærne har en annen jobb: ett tre for å skrive endringer, ett tre for å skille dem og en for å peke på din siste forpliktelse på en gren i Git repo.
Filer hvis innhold kan endres, er i arbeidskatalogen. Filer som er plassert i indeksen din, blir forberedt på å bli pakket inn i et commit-objekt. Disse forpliktelsene lagres i Git-depotet ditt.
Filer som allerede er begått, er komprimerte filer. De er hashed gjennom en SHA-1, en kryptografisk hash-funksjon. Begge filversjonene i indeksen og forplikte seg er lagret i Git repo, som bare er en .git rektor på rutenivået av innpakningen din.
Arbeidsgruppen representerer de faktiske filene i datamaskinens filsystem som er tilgjengelig for kodeditoren din for å bruke endringer. Arbeidskatalogen er en versjon av et bestemt forpliktelse, et bestemt øyeblikksbilde av et prosjekt som du sjekket ut. Det er den versjonen av Git-historien som HEAD peker på, til enhver tid.
"Checked out" betyr at du har de dekomprimerte versjoner av filer som ble trukket ut av Git-arkivet, tilgjengelig for redigering. Indeksen representerer hva som spores. Du kan også si at det er en liste over alle filene som er relevante for Git-depotet ditt.
Indeksen går med et par navn. Når folk snakker om oppsamlingsområdet, iscenesatt filer, hurtigbuffer eller katalogbuffer, snakker de alle om indeksen. Du kan se indeksen som utkastsone for ditt neste forpliktelse, et midlertidig område for å forberede neste forpliktelse.
HEAD er den delen av git som peker på grener, som hovedgrenen som standard. Det er en referanse, og den har en ganske enkel, men svært viktig jobb. HEAD peker på den nå sjekket ut grenen, og som igjen peker tilbake til siste forpliktelse fra den grenen. HEAD kan flytte ikke bare i tide (når du sjekker ut tidligere forpliktelser), men det beveger seg også når du oppretter nye grener eller bare bytter til andre grener.
Det er også poenget i Git-historien din, som du kan plassere ditt neste forpliktelse til, forelder for ditt neste forpliktelse. Med hver ny forpliktelse erstatter den sin referanse til grenen som nå er sjekket ut som standard, hovedgrenen, selvfølgelig.
Så i virkeligheten er HEAD en referanse som ofte endrer seg og peker på to ting: selve grenen, og gjennom den, forplikter den siste grenen.
La oss ta en nærmere titt på arbeidsflyten for å håndtere filer i Git. Det er viktig å forstå hvordan alle disse brikkene passer sammen. Du får en mye enklere tid til å gi mening om mer avanserte funksjoner og konsepter i Git etter det.
Her er et eksempel:
I dette eksemplet har vi begått to versjoner av vår fil. Og du kan se at versjonene i repo, indeksen og arbeidskatalogen er en og samme. Siden disse filene allerede er sporet, vil Git legge merke til eventuelle forskjeller når du endrer noen av disse spore filene i arbeidskatalogen.
Når du kjører git status kommando, vil du se en liste over filer som er endret, farget i rødt. Dette indikerer at du har forskjeller mellom arbeidskatalogen din - representert av koden i kodeditoren din - og indeksen din, som representerer versjoner av filer fra en bestemt forpliktelse, oftest den siste forpliktelsen.
Du kan nå kjøre git add kommandoen for å sette disse endringene fra arbeidskatalogen til indeksen hvor du lagret filene. git status vil da vise filene som er lagt til indeksen farget i grønt. Dette betyr at endringene dine er klare til å bli pakket inn i en ny forpliktelse, som HEAD kan peke på og bygge på.
En grønn liste over filer betyr ganske enkelt at versjonene av de iscenesatte filene i indeksen er forskjellige fra versjoner av filer som allerede var forpliktet tidligere. Når du kjører git commit, Disse iscenesatte filene blir satt inn i et nytt commit-objekt. De git commit kommando vil lagre de faktiske filnavnene, innholdet i hver fil, forfatterinformasjon, metadata og lignende, i en ny gjenstand.
Dette begår objektet, som nå bor i en .git katalog i repo, blir den nye referansen som HEAD peker på. Det peker tilbake til tidligere forpliktelser, og er toppen av isfjellet på en måte. Etter at vi har opprettet vår forplikte gjenstand, er vi tilbake i begynnelsen av syklusen.
Forpliktelsen som HEAD peker på i repo, samsvarer igjen med versjoner i indeksen og arbeidskatalogen, som er klar for at nye endringer skal vises og forpliktes. Slutt på historien.
Hvis du fant dette nyttig, hvorfor ikke sjekk ut noen flere Git-kurs?
Du kan se vår Introduksjon til Git og GitHub, eller prøv de andre Coffee Break-kursene i denne serien:
Accentsconagua