Git --fast-version-control

1.3 Komme i gang - Grunnleggende Git

Grunnleggende Git

Så, hva er Git i et nøtteskall? Dette er en veldig viktig seksjon og ta innover seg, fordi om du forstår hva Git er og det fundamentelle rundt hvordan det virker, så vil det å bruke Git effektiv, sannsynligvis bli mye enklere for deg. Etter som du lærer Git, prøv å tøm tankene for de tingene du vet om andre VCSer, som Subversion og Perforce; å gjøre det vil hjelpe deg å unngå småforvirring når du bruker verktøyet. Git lagrer og tenker på informasjon veldig annerledes disse andre systemene, selv om bruker grensesnittet er ganske likt; å forstå de forskjellene vil hjelpe deg unngå å bli forvirret mens du bruker det.

Bilder, Ikke Forskjeller

Hovedforskjellen mellom Git og andre VCS verktøy (inklusivt Subversion og dens venner) er hvordan den tenker på sin data. Konseptuelt, så lagrer de fleste andre systemer informasjon som en liste over filbaserte endringer. Disse systemene (CVS, Subversion, Perforce, Bazaar, og så vidre) tenker på informasjon som det tar vare på som et sett med filer og endringene gjort til hver fil over tid, som illustrert i Figur 1-4.


Figure 1-4. Andre systemer pleier å lagre data som endringer til en grunnleggende versjon av hver fil.

Git verken tenker eller lagrere dataen på denne måten. Istedet så tenker Git på dataen mer som et sett med bilder av mini filsystemer. Hver gang du commit-er, eller lagrere tilstanden for prosjektet ditt i Git, så tar den i hovedask et bilde av hvordan alle filene dine ser ut i det øyeblikket of lagrer en referanse til det bildet. For å være effektiv, hvis filer ikke har blitt endre, så lagrer ikke Git filen igjen, den bare linker til forrige indentiske fil som den allerede har lagret. Git tenker på dataen mer som Figure 1-5.


Figure 1-5. Git lagrere data som et bilde av prosjektet over tid.

Dette er et viktig skille mellom Git og nesten alle andre VCSer. Det gjør at Git revurderer nesten alle aspekter av versjonkontroll som de fleste andre systemer kopierte fra den forrige generasjonen. Dette gjør Git mer til et mini-filsystem som har utrolig kraftige verktøy bygd oppå seg, istedet for bare en VCS. Vi vil utforske noen av fordelene du vil få ved å tenke på dataen din på denne måten når vi dekker Git avgrening i Kapitell 3.

Nærmest Alle Operasjoner Er Lokale

De fleste operasjonene i Git trenger bare lokale filer og resurser for å operer - generelt sett så er ikke informasjon fra noen annen maskin på nettverket ditt nødvendig. Hvis du har brukt en CVCS hvor de fleste operasjoner har den type nettverk forsinkelse, så vil dette aspektet av Git få deg til å tenke at gudene for fart har velsignet Git med uparallelle krefter. Fordi du har hele historien til prosjektet rett der på den lokale disk, så virker de fleste operasjoner som om de nesten skjer med en gang.

For eksempel, for å se gjennom historien til prosjektet, så trenger ikke Git å gå til serveren for å få historien, og vise det til deg- den simpelthen leser den rett fra din likale database. Dette betyr at du ser prosjekt historien nesten med en gang. Hvis du ønsker å se endringene introdusert mellom den nåværende versjonen av filen og filen for en måned isden, så kan Git sjekke den filen fra en måned siden og gjøre en lokal forskjell kalkulasjon, istedet for å enten måtte spøre en server om å gjøre det, eller å måtte hente en eldre versjon av filen fra den serveren for å gjøre det lokalt.

Dette betyr også at det er veldig lite du ikke kan gære om du er offline eller ikke er på VPN. Du kan gå på et fly, eller et tog og så ønske å jobbe litt, og du kan gladelig comitte det fram til du kommer til en nettverkstilkobling for å laste det opp. Hvis du går hjem og ikke kan få VPN klienten til å virke skikkelig, så kan du fortsatt jobbe. I mange systemer, så er det enten umulig å gjøre, eller smertefult. I Perforce, for eksempel, så kan du ikke gjære stort når du ikke er koblet til serveren, og i Subversion og CVS, så kan du endre filer, men du kan ikke bruke commit på endringene dine til databasen (siden databasen din er offline). Dette virker kanskje ikke som noe stort, men du kan bli overrasket over hvor stor forskjell det kan utgjøre.

Git Har Integritet

Alt i Git er sjekksummert før det er lagret, og så blir den referert til med den sjekksummen. Dette betyr at det umulig å endre innhodlet på en fil eller mappe uten at Git vet om det. Denne funksjonaliteten er bygd inn i Git på de laveste nivåene og er viktig del av dens filosofi. Du kan ikke miste informasjon når den prossesserer endringer eller ende opp med en korrupt fil uten at Git er i stand til å oppdage det.

Mekanismen Git bruker for denne sjekksummeringen er kalt en SHA-1 hash. Dette er en 40-tegn lang tekst satt sammen av hexadecimal-tegn (0-9 og a-f) og er kalkulert baser på innholdet av en fil og mappe structuren i Git. En SHA-1 hash ser ut noe sånt som dette:

24b9da6552252987aa493b52f8696cd6d3b00373

Du vil se disse hash verdiene overalt i Git fordi den bruker dem så mye. Git lagrer faktisk alt, ikke med navn, men i Git databasen adresserbart med hash verdien av innholdet dens.

Git Legger Generelt Bare Til Data

Når du gjør ting i Git, så vil nesten alle bare legge til data til Git databasen. Det er veldig vanskelig å få systemet til å gjøre noe som ikke kan angres, eller få det til å slette data på en eller annen måte. Som i en hver VCS, så kan du miste eller rote til endringer du ikke har commitet enda; men etter du har commited et bilde inn i Git, så er det veldig vanskelig å miste det, spesielt om du jevnlig bruker push for å sende databasen til en annen repository.

Dette gjør det å bruke Git til en gledelig opplevelse fordi vi vet at vi kan eksperimentere uten fare for å virkelig rote til ting skikkelig. For en mer dypere innsyn i hvoradn Git lagerer data og hvordan du kan få tilbake data som virker tapt, se Kapitel 9.

De Tre Tilstandene

Følg med. Detter er viktigeste å huske om Git om du ønsker at resten av læringsprossessen din skal gå flytende. Git har tre hoved tilstandet som filene dine kan være i: committed, modified, og staged. Commited betyr at dataen er laget trygt i din lokale database. Mofigied betyr at du har endret på filen men ikke har committed den til databasen enda. Staged betyr at du har markert en modified fil i dens nåværende versjon til å gå inn i ditt neste commit bilde.

This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area.


Figure 1-6. Arbeidsmappe, staging området, og git mappe.

Git mappen er der Git lagere metadata og objekt databasen for prosjektet ditt. Dette er den mest viktige delen av Git, og det er det som er kopier når du kloner et repository fra en annen maskin.

Arbeidsmappen er en enkel checkout av en versjon av prosjektet. Disse filene er dratt ut av den komprimerte databasen i Git mappen og plassert på disken slik at du kan bruke eller modifisere det.

Staging området er en enkelt fil, generelt holdt i Git mappen din, som lagrer informasjon om hva som vil gå inn i din neste commit. Det er noen ganger referert til som indeksen, men det begynner å bli det vanlige å kalle det staging området.

Den grunnleggende Git arbeidsmåten er litt som dette:

  1. Du modifiserer filer i arbeidmappa.
  2. Du stage-er filene, og lager bilder av den til staging området.
  3. Du gjør en commit, som tar filene som de er i staging området og lagrer det bildet permanent i Git mappen din.

Hvis en bestemt versjon av en fil er i git mappen, så er den ansett som comitted. Hvis den er modifisert men har blitt lagt til i staging området, så der den staged. Og hvis den var endret siden den var sjekket ut men ikke blitt staged, så er den modifisert. I Kapitel 2 så vil du lære om disse tilstande og hvordan du kan utnytte deg av dem eller hoppe over staged-delen helt.