Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Lära Grundläggande om Rebase | Mer Avancerade Arbetsflöden
Github-Grunder
course content

Kursinnehåll

Github-Grunder

Github-Grunder

1. Introduktion till GitHub
2. Grundläggande Interaktion med Fjärrservrar
3. Mer Avancerade Arbetsflöden

book
Grundläggande om Rebase

Skapa en commit på main-grenen

Börja med att göra en commit direkt på den fjärranslutna main-grenen genom att redigera filen README.md i det fjärranslutna arkivet. Detta kommer att leda till att main-grenen och feature/payment-grenen får en avvikande commit-historik.

Här är raden som lades till i filen:

Här är det aktuella commit-meddelandet:

Förståelse av rebase

Som vi nämnde i föregående kapitel, när feature-grenen har granskats och testats, kan och bör den slås samman tillbaka till main-grenen. Hittills har vi endast använt kommandot git merge för detta ändamål. Ett annat tillvägagångssätt är dock att använda kommandot git rebase.

Note
Läs mer

Rebase är processen att flytta eller kombinera en sekvens av commits till en ny bas-commit. Detta görs genom att spela upp ändringarna från en gren på en annan gren, vilket resulterar i en linjär commit-historik.

När vi skapar en gren spårar Git den senaste commit på båda grenarna. Om endast en gren har nya ändringar kan Git snabbspola framåt och tillämpa ändringarna. Om båda grenarna har nya ändringar skapar Git en ny merge-commit, vilket resulterar i en trevägs-sammanslagning.

Så här skulle en trevägs-sammanslagning se ut i vårt fall, där C4 var den senaste commit på feature/payment-grenen innan sammanslagningen:

Trevägs-sammanslagningar kan dock försvåra felsökning på grund av uppdelad, icke-linjär historik. Genom att använda rebase ändrar vi basen för våra commits och spelar upp dem ovanpå den nya basen, vilket gör att Git kan utföra en fast-forward-sammanslagning och bibehålla en linjär historik.

Här är en animation som illustrerar hur rebase kan utföras i vårt fall (commit-identifierarna motsvarar inte de verkliga här):

Note
Observera

När du rebasar en gren skriver du i praktiken om dess historik. Det innebär att de gamla commiten ersätts med nya, som har andra identifierare (hashsummor) eftersom de baseras på andra ögonblicksbilder av koden. Som visas i animationen ovan ändrades identifieraren för committen på grenen feature/payment efter rebase.

question mark

Vad är huvudsyftet med att använda git rebase istället för git merge?

Select the correct answer

Var allt tydligt?

Hur kan vi förbättra det?

Tack för dina kommentarer!

Avsnitt 3. Kapitel 4

Fråga AI

expand

Fråga AI

ChatGPT

Fråga vad du vill eller prova någon av de föreslagna frågorna för att starta vårt samtal

course content

Kursinnehåll

Github-Grunder

Github-Grunder

1. Introduktion till GitHub
2. Grundläggande Interaktion med Fjärrservrar
3. Mer Avancerade Arbetsflöden

book
Grundläggande om Rebase

Skapa en commit på main-grenen

Börja med att göra en commit direkt på den fjärranslutna main-grenen genom att redigera filen README.md i det fjärranslutna arkivet. Detta kommer att leda till att main-grenen och feature/payment-grenen får en avvikande commit-historik.

Här är raden som lades till i filen:

Här är det aktuella commit-meddelandet:

Förståelse av rebase

Som vi nämnde i föregående kapitel, när feature-grenen har granskats och testats, kan och bör den slås samman tillbaka till main-grenen. Hittills har vi endast använt kommandot git merge för detta ändamål. Ett annat tillvägagångssätt är dock att använda kommandot git rebase.

Note
Läs mer

Rebase är processen att flytta eller kombinera en sekvens av commits till en ny bas-commit. Detta görs genom att spela upp ändringarna från en gren på en annan gren, vilket resulterar i en linjär commit-historik.

När vi skapar en gren spårar Git den senaste commit på båda grenarna. Om endast en gren har nya ändringar kan Git snabbspola framåt och tillämpa ändringarna. Om båda grenarna har nya ändringar skapar Git en ny merge-commit, vilket resulterar i en trevägs-sammanslagning.

Så här skulle en trevägs-sammanslagning se ut i vårt fall, där C4 var den senaste commit på feature/payment-grenen innan sammanslagningen:

Trevägs-sammanslagningar kan dock försvåra felsökning på grund av uppdelad, icke-linjär historik. Genom att använda rebase ändrar vi basen för våra commits och spelar upp dem ovanpå den nya basen, vilket gör att Git kan utföra en fast-forward-sammanslagning och bibehålla en linjär historik.

Här är en animation som illustrerar hur rebase kan utföras i vårt fall (commit-identifierarna motsvarar inte de verkliga här):

Note
Observera

När du rebasar en gren skriver du i praktiken om dess historik. Det innebär att de gamla commiten ersätts med nya, som har andra identifierare (hashsummor) eftersom de baseras på andra ögonblicksbilder av koden. Som visas i animationen ovan ändrades identifieraren för committen på grenen feature/payment efter rebase.

question mark

Vad är huvudsyftet med att använda git rebase istället för git merge?

Select the correct answer

Var allt tydligt?

Hur kan vi förbättra det?

Tack för dina kommentarer!

Avsnitt 3. Kapitel 4
some-alt