Rebasering: vad det är, hur rebase fungerar och arbete med Git

Vad är rebase i Git

Rebase — är ett Git-kommando som ombaserar den aktuella grenen på den angivna grenen: tar alla commits från den aktuella grenen, sparar dem tillfälligt, flyttar grenpekaren till mål-commiten och tillämpar de sparade commits sekventiellt ovanpå den. Resultatet — historiken ser ut som om utvecklaren arbetade direkt från den senaste commiten av mål-grenen.

Grundläggande syntax: git rebase main — när du befinner dig i feature-grenen flyttar detta kommando alla feature-commits till toppen av main. Git använder en three-way merge-strategi för varje commit separat. Om commit A redan finns i mål-grenen (bestäms via hash), hoppar Git automatiskt över den, vilket undviker dubbelarbete av ändringar.

Rebase stöder också onto-läget för att flytta en del av commits: git rebase --onto target start end — denna form gör det möjligt att extrahera ett intervall av commits från en gren och tillämpa dem ovanpå en annan. Till exempel kommer git rebase --onto main feature~3 feature att flytta de tre senaste commits av feature-grenen till toppen av main.

# Växla till feature-gren
git checkout feature

# Ombasera feature på main
git rebase main

# Efter lyckad rebase — historiken är linjär
git log --oneline --graph

# Flytta de 3 senaste commits till main
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: viktigaste skillnaderna

Rebase och merge löser samma uppgift — att kombinera ändringar från olika grenar — men gör det på fundamentalt olika sätt. Merge bevarar den fullständiga sammanslagningshistoriken genom att skapa en merge-commit med två föräldrar. Rebase skriver om historiken och gör den linjär. Valet mellan dem beror på teamets arbetsflöde och reglerna för arbete med repot.

Den största skillnaden — hur sammanslagningsfaktumet registreras. Merge bevarar: “på denna punkt slog vi samman feature i main” — detta är informativt för projektets historik, men skräpar ner loggen vid frekventa sammanslagningar. Rebase visar: “feature-commits gjordes sekventiellt från mains senaste tillstånd” — detta är rent, men döljer det faktum att arbetet utfördes parallellt.

Den andra skillnaden — hantering av konflikter. Vid merge löses konflikter en gång och lösningen registreras i merge-commiten. Vid rebase kan konflikter uppstå för varje flyttad commit och varje kräver separat lösning. Detta är mer tidskrävande, men ger mer exakt kontroll över vilka ändringar som hamnar i den slutliga versionen.

Interaktiv rebase: kommandon och flaggor

Interaktiv rebase (git rebase -i) — är ett läge där Git öppnar en redigerare med en lista över commits och tillgängliga åtgärder för var och en av dem. Utvecklaren kan skriva om historiken innan den skickas till fjärrrepot. Detta är det främsta verktyget för att hålla commits rena i feature-grenen.

Tillgängliga kommandon i interaktivt läge: pick (lämna commiten som den är), reword (ändra commit-meddelandet), edit (stanna för ändringar), squash (slå ihop med föregående commit, behåll båda meddelandena), fixup (slå ihop, kasta meddelandet), drop (ta bort commit). Varje kommando anges före commit-hashen i den öppnade redigeraren.

Squash och fixup — de mest använda kommandona för att slå ihop commits. Om en utvecklare har gjort 5 små commits med rättelser under arbetet, kommer squash att slå ihop dem till en logisk commit med ett meningsfullt meddelande. Fixup är användbart för att korrigera skrivfel: ändringarna hamnar i den föregående commiten utan att spara sitt eget meddelande.

# Öppna redigeraren för de 4 senaste commits
git rebase -i HEAD~4

# Redigeraren kommer att visa:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# Efter sparande — Git utför rebase
# och öppnar redigeraren för sammanslaget commit-meddelande

# Auto-squash utan att öppna redigeraren
git rebase -i HEAD~4 --autosquash

Flaggan --autosquash ställer automatiskt in fixup/squash för commits vars meddelanden börjar med fixup! eller squash!. Detta påskyndar arbetet om utvecklaren i förväg markerar commits för senare sammanslagning. Flaggan --committer-date-is-author-date bevarar det ursprungliga datumet för commiten vid ombasering — användbart för att bevara kronologin i historiken.

Konfliktlösning vid rebase

Konflikter vid rebase uppstår när Git inte automatiskt kan tillämpa den flyttade commiten på grund av motsättningar med ändringar i mål-grenen. Till skillnad från merge där konflikten löses en gång, vid rebase kan varje commit orsaka en konflikt och måste lösas sekventiellt för varje commit från den äldsta till den nyaste.

När en konflikt uppstår, pausar Git rebase och rapporterar vilken commit som orsakade problemet. Utvecklaren öppnar konfliktfilen (Git markerar konfliktområden med markörer <<<<<<<, =======, >>>>>>>), redigerar den, lägger till i index (git add) och fortsätter rebase med kommandot git rebase --continue. Om ingen lösning hittas — git rebase --abort avbryter ombaseringen helt.

Tips: vid flera konflikter är det effektivare att använda git mergetool, som öppnar en visuell redigerare för att lösa motsättningar. Man kan också hoppa över den problematiska commiten (git rebase --skip), men detta tar bort dess ändringar från den slutliga historiken, vilket sällan är rätt lösning.

# Starta rebase med konflikt
git rebase main
# Auto-merging file.txt
# KONFLIKT (innehåll): Sammanslagningskonflikt i file.txt

# Kontrollera status
git status
# båda modifierade: file.txt

# Redigera konfliktområden → git add → fortsätt
git add file.txt
git rebase --continue

# Vid osäkerhet — avbryt
git rebase --abort

När man inte ska rebasa

Gyllene regeln för rebase: ombasera aldrig commits som redan har skickats till fjärrrepot och är tillgängliga för andra utvecklare. Eftersom rebase skriver om commit-hashar kommer kollegor att stöta på konflikter vid synkroniseringsförsök — deras lokala historik kommer att vara oförenlig med den omskrivna fjärrhistoriken.

Situationen där rebase är kategoriskt förbjudet: om någon redan har skapat en gren baserad på dina commits (till exempel har din kollega gjort en feature från din feature), kommer ändring av historiken att förstöra hans arbete. I sådana fall ska merge användas. Det rekommenderas inte heller att rebasa precis före deadline — ett misstag vid konfliktlösning kan ta längre tid än förväntat och blockera releasen.

Undantag: om grenen endast används av en utvecklare (personlig feature-gren, opublicerad eller publicerad i draft-läge), är rebase före push standardpraxis. Efter publicering och påbörjat teamarbete — endast merge. GitHub och GitLab erbjuder som standard squash merge som en kompromiss: det slår ihop commits till en, men skriver inte om mål-grenens historik.

• Offentliga grenar (main, develop, release) — rebase helt förbjudet.
• Andras commits — om grenen innehåller commits från en annan utvecklare är rebase oacceptabelt.
• Före release — risken för konflikter är högre: merge är säkrare en dag före deadline.
• Grenar med taggar — att flytta en commit med en tagg bryter mot konventionerna för semantisk versionhantering.
• CI/CD kopplat till hashar — vissa distributionssystem identifierar byggen via commit-hash; rebase bryter spårningen.

Praktiskt arbetsflöde med rebase

I moderna team används oftast rebase-orienterat arbetsflöde i kombination med GitHub Flow. Processen ser ut så här: utvecklaren skapar en feature-gren från main, arbetar i den, synkroniserar periodiskt via git rebase main och utför före skapandet av en pull request en interaktiv rebase för att rensa historiken.

Efter att PR har skapats (om nya ändringar från main behöver hämtas) används git pull --rebase main istället för vanlig git pull. Detta gör det möjligt att hämta ändringar utan att skapa en onödig merge-commit. Git pull med flaggan --rebase är likvärdigt med git fetch + git rebase — Git laddar först nya commits, sedan ombaserar det lokala ändringar ovanpå dem.

Git gör det möjligt att ställa in rebase som standardbeteende för pull: git config --global pull.rebase true. Efter denna konfiguration utför git pull alltid rebase istället för merge. Om vanlig pull behövs — används git pull --no-rebase. Många team aktiverar också autostash: git config --global rebase.autoStash true — detta döljer automatiskt ocommittade ändringar före rebase och återställer dem efteråt.