Rebase: vad är det, skillnad från Merge och funktionsprincip

Vad är Rebase?

Rebase (ombasering) — är en Git-operation som flyttar commits från den aktuella grenen till en ny referenspunkt (bas). Istället för att skapa en merge-commit tar rebase varje commit från källgrenen och tillämpar den i tur och ordning ovanpå den nya basen. Resultatet är en linjär sekvens av commits utan förgreningar.

Namnet rebase kommer från „re-base" — att ändra bas. Om merge slår ihop två grenar vid en punkt, flyttar rebase faktiskt hela din gren till en ny plats och skapar illusionen att du började utvecklingen från målgrenens aktuella tillstånd. Detta skapar en bild av perfekt sekventiellt arbete.

Enligt Atlassian, 2025 lägger team som använder rebase för feature-grenar 30% mindre tid på att analysera commit-historiken jämfört med team som enbart använder merge. Linjär historik förenklar git blame, bisect och visning av loggen via git log --oneline.

Grundläggande skillnad från Merge

Merge slår ihop grenar genom att skapa en commit med två föräldrar. Rebase skriver om historiken: nya commits skapas på nytt med nya hash-värden, även om ändringarna i dem är identiska med originalen. Detta innebär att rebase ändrar SHA-identifierarna för commits, vilket är kritiskt för publika grenar.

Hur fungerar Rebase

Rebase-mekanismen består av fyra steg: Git bestämmer den gemensamma anfadern (merge base) för den aktuella och mål-grenen, och tillämpar sedan varje commit från den aktuella grenen i tur och ordning ovanpå mål-grenen. Om en konflikt uppstår vid något steg — stannar rebase och väntar på en lösning.

# Utgångssituation: feature ligger 3 commits efter develop
git checkout feature/new-login
git rebase develop

# Git tar 3 commits från feature och tillämpar dem på develop
# Om det inte finns några konflikter — rebase slutförs automatiskt
# Om det finns — Git stannar vid den konfliktfyllda committen

Efter rebase innehåller feature-grenen alla commits från develop plus sina egna commits, som ser ut som en fortsättning på develop. Detta gör det möjligt att slå samman till develop via fast-forward, utan att skapa en merge-commit.

Steg-för-steg-process

Låt oss titta på ett detaljerat exempel: en utvecklare skapade en feature-gren från develop, gjorde två commits, och under tiden lade andra utvecklare till tre commits i develop. Rebase flyttar featurens två commits till en ny plats och skapar kopior med nya SHA-värden.

# 1. Skapa feature-gren
git checkout -b feature/payment-refactor develop

# 2. Gör commits i feature
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Uppdatera develop (kollegors arbete)
git checkout develop
git pull

# 4. Ombasa feature ovanpå nya develop
git checkout feature/payment-refactor
git rebase develop

# 5. Nu kan feature slås samman via fast-forward
git checkout develop
git merge feature/payment-refactor

Om en konflikt uppstår vid steg 4, stannar Git vid den problematiska committen. Utvecklaren löser konflikten, gör git add och kör git rebase --continue. Om en commit behöver hoppas över — git rebase --skip, om hela rebase ska avbrytas — git rebase --abort.

Automatisk överhoppning av tomma commits

Flaggan --empty styr rebase-beteendet vid tomma commits — situationer där alla ändringar i committen redan finns i mål-grenen. Som standard stannar rebase och begär ett beslut. Med flaggan --empty=drop hoppar Git automatiskt över sådana commits utan att stanna, vilket snabbar upp massombasering med ett stort antal commits.

Interaktiv Rebase

Interactive rebase (git rebase -i) — ett kraftfullt verktyg för att redigera commit-historiken. Det öppnar en editor med en lista över commits och nyckelkommandon: pick (behåll), reword (ändra meddelande), edit (ändra innehåll), squash (slå ihop med föregående), fixup (slå ihop utan meddelande), drop (ta bort).

# Interaktiv rebase av de senaste 4 commits
git rebase -i HEAD~4

# I editorn öppnas rebase-planen:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Vi ändrar till:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Resultat: tre commits (inloggningsskärm, validering, layout) komprimeras till en, och committen med kommentarer tas bort. Detta gör det möjligt att presentera en ren historik utan utkast och korrigeringar för kodgranskning. Interactive rebase är standardverktyget för att förbereda en feature-gren inför en Pull Request.

Rebase vs Merge: jämförelse

Rebase och Merge löser samma uppgift — integration av ändringar — men på fundamentalt olika sätt. Valet mellan dem beror på vilken historik du vill se i git log och vem mer som arbetar med din gren.

Praktisk regel: använd merge för integration i gemensamma grenar (develop, main) och rebase för att uppdatera personliga feature-grenar till aktuellt tillstånd. Många team kombinerar: rebase feature på develop, sedan --no-ff merge till develop.

Inverkan på git bisect

Git bisect — ett verktyg för att hitta committen som introducerade en regression. Vid användning av merge passerar git bisect korrekt genom merge-commits med hänsyn till båda föräldrarna. Vid rebase fungerar bisect snabbare eftersom historiken är linjär och inte kräver förgrening. Men om rebase gjordes efter att commits blev kända för teamet, går de ursprungliga SHA-värdena förlorade och bisect kanske inte hittar den problematiska committen.

När ska Rebase användas

Rebase är optimal i tre scenarier: förberedelse av feature-gren för Pull Request, uppdatering av personlig gren till aktuellt tillstånd för main/develop och rensning av historik före sammanslagning. I varje fall förbättrar rebase historikens läsbarhet utan risk för teamarbete.

Innan en Pull Request rekommenderas att utföra interactive rebase för att slå ihop arbetscommits (WIP, korrigeringar efter granskning) till meningsfulla logiska enheter. Detta underlättar kodgranskning: granskaren ser inte 15 små commits utan 3-5 strukturerade ändringar med begripliga meddelanden.

För uppdatering av feature-gren är rebase att föredra framför merge eftersom det inte skapar onödiga merge-commits. Om du periodvis gör git rebase develop inom feature-grenen kommer det efter den slutliga sammanslagningen inte att finnas en kaskad av 10 merge-commits — bara rena feature-commits ovanpå develop.

Rensning av historik via interactive rebase före sammanslagning gör det möjligt att dölja mindre korrigeringar (skrivfel, formatering) och gruppera commits efter funktionalitet. Git-meddelanden bör följa konventionen Conventional Commits (fix:, feat:, refactor:, docs:), vilket genererar en automatisk changelog.

Risker och regler för Rebase

Rebase — en farlig operation om den tillämpas felaktigt. Den största risken — omskrivning av publicerad historik. Om en utvecklare rebasar en gren som andra redan har push-at och använder, desynkroniseras deras lokala kopior och de måste utföra en force-pull med risk för dataförlust.

• Gyllene regeln: rebasa aldrig commits som redan finns i det delade förvaret. Detta gäller alla grenar som andra teammedlemmar har tillgång till
• Force push: efter rebase av lokal feature-gren krävs push med flaggan --force-with-lease, som är säkrare än --force eftersom den kontrollerar om någon har uppdaterat grenen på servern
• Förlust av kontext: rebase förstör information om när och från vilken gren feature-grenen skapades. Om det är viktigt att bevara grenens skapelsedatum — använd merge
• Konflikter: vid rebase måste konflikter lösas för varje commit separat, vilket kan vara tröttsamt vid ett stort antal commits

För att minimera risker, följ regeln: rebase endast för personliga grenar som inte har publicerats. Om grenen redan finns i det delade förvaret — använd merge med --no-ff. Vid behov av rebase av en publicerad gren — varna teamet och samordna force push i förväg.

Automatiskt skydd mot farlig rebase implementeras via server-side hooks: en pre-receive hook på Git-serverns sida kan kontrollera om push skriver om publicerade commits. GitHub och GitLab tillhandahåller inbyggt skydd för skyddade grenar — force push blockeras om inte skyddet tas bort av en administratör.