Synka din lokala Git-branch med fjärren utan att tappa arbete

När en lokal webbplats eller kodgren har glidit isär från GitHub eller GitLab kan det kännas enklast att skriva över allt med fjärrversionen. Det går oftast med git fetch följt av git reset --hard, men bara om du först har koll på vilken branch som är rätt och vilka lokala ändringar du kan förlora.

Hämta fjärrens senaste läge innan du återställer

En branch som heter origin/main är din lokala referens till fjärrens branch, inte en livevy av servern. Om den inte har uppdaterats nyligen kan en återställning landa på en äldre version. Börja därför med git fetch, som hämtar nya commits och uppdaterar fjärrspårade brancher utan att slå ihop ändringarna med din lokala branch, enligt Git-dokumentationen för fetch.

Kontrollera sedan var du befinner dig och vilka ändringar som finns:

git status
git branch -vv
git fetch origin

Utdata från git branch -vv visar normalt aktuell branch och dess upstream, alltså branchen som den följer. Om projektets huvudbranch heter main och fjärren heter origin, är målet ofta origin/main. Kontrollera namnet i just ditt repo innan du kör ett destruktivt kommando.

Välj reset när du vill kasta lokalt arbete

Om du vill att den lokala branchen, indexet och spårade filer ska motsvara fjärrens senaste hämtade commit kan du köra:

git reset --hard origin/main

Byt ut origin/main mot rätt fjärr och branch. Kommandot flyttar den aktuella branchens spets och skriver om stagingområdet och arbetskatalogen så att de matchar målcommitten. Enligt Git-dokumentationen för reset kan --hard även skriva över ospårade filer som ligger i vägen för filer från målcommitten.

Reset ändrar din lokala branch, inte fjärrservern. En senare push är en separat åtgärd. Jag tycker att det är klokast att läsa git status en sista gång och kontrollera branchens namn precis före reset, eftersom ett enda felaktigt mål kan kassera commits du ville behålla.

Spara ändringar innan reset om de kan behövas

Det är lätt att blanda ihop en commit med en ändring som bara finns i arbetskatalogen. En commit ligger i Git-historiken, medan ändringar som inte committats kan försvinna när du kör reset --hard. Om något är osäkert, skapa först en tillfällig commit eller lägg arbetet i stash.

git stash push -u -m "arbete före reset"
git fetch origin
git reset --hard origin/main

Flaggan -u tar med ospårade filer i stashen. Stash är en tillfällig lagring, inte en ersättning för en genomtänkt backup; återställ ändringarna senare med exempelvis git stash pop, och lös eventuella konflikter om de uppstår. Om filerna är viktiga och svåra att återskapa är en separat kopia eller en tillfällig branch ett tryggare skydd.

Se skillnaden mellan lokala commits och osparat arbete

Två olika saker kan ligga före fjärrversionen: ändringar som aldrig committats och commits som bara finns lokalt. Det första syns i git status; det andra kan du granska i commitloggen. Skillnaden avgör om du bara behöver spara filer eller också skapa en räddningsbranch.

git status
git log --oneline --decorate --graph --all -n 12

Om loggen visar lokala commits som saknas på fjärren, sparar en stash inte dem. Skapa i stället en branch vid nuvarande commit innan återställningen:

git branch backup-fore-reset
git fetch origin
git reset --hard origin/main

Här pekar backup-fore-reset på din nuvarande commit, så att de lokala commitsen fortfarande går att nå efter reset. Om branchen redan har delats med andra bör du vara extra försiktig med att skriva om historiken och samordna ändringen med teamet.

Återställ borttappade commits med reflog

En reset kan kännas slutgiltig, men Git registrerar lokala förflyttningar av branchens spets i refloggen. Den kan hjälpa dig hitta committen som branchen pekade på före misstaget. Kör:

git reflog

Leta efter posten före reset och kopiera dess commit-id. Skapa sedan en räddningsbranch där, så att committen får ett tydligt namn:

git branch rescue-branch 

Git dokumenterar också ORIG_HEAD, som i vissa operationer sparar branchens tidigare spets; efter en reset kan den ibland peka på den tidigare committen. Men räkna inte med att den alltid är rätt återställningspunkt. Refloggen är användbar för lokalt borttappad historik, medan ospårade filer som raderats inte nödvändigtvis går att få tillbaka den vägen.

Låt ospårade filer vara ett separat beslut

Efter reset kan nya filer ligga kvar, eftersom de inte ingår i den spårade historiken. Det kan vara exempelvis en lokal konfigurationsfil eller en exporterad bild som Git aldrig har följt. Att ta bort dem kräver ett separat kommando, så kontrollera först vad Git skulle radera:

git clean -nd

Om listan bara innehåller sådant du verkligen vill ta bort kan git clean -fd radera ospårade filer och mappar. Lägg inte till -x av slentrian, eftersom den även tar med ignorerade filer, som lokala byggfiler eller miljöinställningar. Om målet är att matcha fjärrens spårade filer räcker reset ofta; kör clean endast när du också vill rensa ospårat innehåll.

Välj den minsta återställning som löser problemet

En full reset är rätt när lokal branch och arbetskatalog ska ersättas av fjärrens tillstånd. Om du bara vill ångra en ändring i en enskild fil behöver du inte flytta hela branchen: återställ filen separat med git restore. Om problemet däremot gäller flera lokala commits, börja med en backup-branch så att historiken finns kvar.

Min tumregel är enkel: osäker på vad som försvinner, spara först; säker på branch och mål, hämta och återställ. Då blir synkningen en medveten lokal ändring i stället för ett chansartat kommando.