En kollega har pushet en endring til prosjektet mens du var i lunsj. Du vil se hva hun har gjort før du fortsetter, men du har selv uferdige endringer i to filer og vil ikke risikere at noe blir overskrevet. Det er her forskjellen på git fetch og git pull betyr noe. Den ene henter bare ned. Den andre henter og fletter inn i koden din.
Hva git fetch gjør
git fetch spør GitHub om det har kommet noe nytt, og laster det ned til maskinen din. Filene du jobber i, blir ikke rørt. Endringene legges i en egen kopi av den eksterne branchen, som Git kaller origin/main, og der blir de liggende til du bestemmer deg.
Kjør git status etter en fetch, og Git sier fra hvor du står:
Your branch is behind 'origin/main' by 1 commit, and can be fast-forwarded. (use "git pull" to update your local branch)
Det betyr at det finnes én ny commit på GitHub som du ikke har i koden din ennå. Det fine med fetch er at du kan se på den før du tar den inn. git log main..origin/main lister commitene du mangler, og git diff main origin/main viser nøyaktig hvilke linjer som er endret.
Hva git pull gjør
git pull gjør to ting etter hverandre: den kjører en fetch, og slår deretter det nedlastede sammen med branchen du står på. Når kommandoen er ferdig, viser terminalen hvilke filer som ble endret, og hvor mange linjer som ble lagt til og fjernet. Åpner du filen i editoren, er kollegaens endring der.
Du trenger altså ikke kjøre fetch før pull. Pull henter selv. Grunnen til å bruke fetch først er at du vil vite hva som kommer før det havner i filene dine, for eksempel når du har uferdige endringer, eller når du mistenker at noen har endret de samme linjene som deg.
- git fetch: henter ned, rører ikke filene dine, trygt å kjøre når som helst.
- git pull: henter ned og slår sammen, endrer filene dine, kan gi merge-konflikt.
Fetch og pull i GitHub Desktop
I GitHub Desktop er det én knapp øverst som skifter navn etter hva som er neste naturlige steg. Har du commits som ikke er lastet opp, står det Push origin. Har du ingenting å pushe, står det Fetch origin. Trykker du på den og det har kommet noe nytt, endres knappen til Pull origin, med et tall som viser hvor mange commits som venter.
Flyten er den samme som i terminalen: fetch laster ned, pull slår sammen. Etter pull finner du kollegaens commit i fanen History, med hvem som gjorde den og hvilke linjer som ble endret.
Når git pull stopper
To ting kan få en pull til å stoppe halvveis, og begge har en enkel forklaring.
Du har uferdige endringer i de samme filene
Har du endret en fil som også er endret på GitHub, og ikke committet det ennå, nekter Git å overskrive arbeidet ditt. Meldingen sier at «your local changes would be overwritten by merge». Du har to valg: committe det du har gjort, eller legge det midlertidig til side med git stash, forklart under.
Dere har endret den samme linjen
Har du committet en endring på en linje som kollegaen også har endret, kan ikke Git velge for deg. Du får en merge-konflikt, og må selv bestemme hvilken versjon som skal stå. Slik leser og løser du den, står i Slik løser du en merge-konflikt i Git.
Legg endringene til side med git stash
git stash tar alt du har endret siden forrige commit og legger det på en hylle. Mappen ser ut som rett etter siste commit, og git status svarer «nothing to commit, working tree clean». Det gjør stash nyttig rett før en pull:
- Kjør git stash for å legge de uferdige endringene til side.
- Kjør git pull for å hente kollegaens endringer.
- Kjør git stash pop for å legge endringene dine tilbake oppå den nye koden.
Har du stashet flere ganger, viser git stash list alt som ligger på hylla. Hver stash har et nummer, og du kan hente frem en bestemt en med git stash pop stash@{1}.
Obs: Stash er ikke en slettknapp. Endringene ligger lagret til du henter dem eller rydder hylla med git stash drop. Vil du kaste endringene i en fil for godt og starte på nytt fra siste commit, bruker du git restore etterfulgt av filnavnet.
En rytme som gir færre overraskelser
De fleste problemer med pull kommer av at det har gått lang tid siden sist. Jo lenger du jobber uten å hente andres endringer, jo større er sjansen for at dere har rørt de samme linjene. En enkel vane holder det meste unna:
- Kjør git pull før du begynner på noe nytt.
- Commit hver gang du er ferdig med en liten del. Du trenger ikke pushe hver gang.
- Kjør git pull igjen rett før du pusher, og løs eventuelle konflikter på din egen maskin.
- Push.
Er du usikker på hvor grensen mellom Git på maskinen din og GitHub i skyen går, er Forskjellen på Git og GitHub et godt sted å begynne. Alle valgene til kommandoen finner du i Git-dokumentasjonen for git pull.
Denne videoen er hentet fra kurset Git og GitHub på Utdannet.no. I det fulle kurset gjør en annen bruker endringer i prosjektet underveis, slik at du øver på fetch og pull med ekte endringer, både i GitHub Desktop og i terminalen, og du lærer git status, add, commit, log, show og diff i samme prosjekt.
