Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Lære Grundlæggende om Rebase | Mere Avancerede Workflows
Github-Grundlæggende
course content

Kursusindhold

Github-Grundlæggende

Github-Grundlæggende

1. Introduktion til GitHub
2. Grundlæggende Interaktion med Fjernlagre
3. Mere Avancerede Workflows

book
Grundlæggende om Rebase

Oprettelse af et commit på main-grenen

Start med at oprette et commit direkte på den eksterne main-gren ved at redigere README.md-filen i det eksterne repository. Dette vil medføre, at main-grenen og feature/payment-grenen får en afvigende commit-historik.

Her er linjen, der blev tilføjet til filen:

Her er den tilsvarende commit-besked:

Forståelse af rebase

Som nævnt i det forrige kapitel, kan og bør feature-grenen, når den er blevet gennemgået og testet, flettes tilbage i main-grenen. Indtil nu har vi kun brugt kommandoen git merge til dette formål. En anden tilgang er dog at bruge kommandoen git rebase.

Note
Læs mere

Rebase er processen, hvor en sekvens af commits flyttes eller kombineres til et nyt base commit. Dette gøres ved at afspille ændringerne fra én gren over på en anden gren, hvilket resulterer i en lineær commit-historik.

Når vi opretter en gren, holder Git styr på det seneste commit på begge grene. Hvis kun én gren har nye ændringer, kan Git fast-forwarde og anvende ændringerne. Hvis begge grene har nye ændringer, opretter Git et nyt merge commit, hvilket resulterer i et trevejs-merge.

Her er et eksempel på, hvordan et trevejs-merge ville se ud i vores tilfælde, hvor C4 var det seneste commit på feature/payment-grenen før sammenfletning:

Dog trevejssammenfletninger kan gøre fejlfinding mere kompleks på grund af den opdelte, ikke-lineære historik. Ved at rebase ændrer vi udgangspunktet for vores commits og afspiller dem oven på det nye udgangspunkt, hvilket gør det muligt for Git at udføre en fast-forward-sammenfletning og opretholde en lineær historik.

Her er en animation, der illustrerer, hvordan rebase kan udføres i vores tilfælde (commit-identifikatorerne svarer ikke til de reelle her):

Note
Bemærk

Når du rebaser en gren, omskriver du i bund og grund dens historik. Det betyder, at de gamle commits erstattes med nye, som har forskellige identifikatorer (hash-summer), fordi de er baseret på forskellige snapshots af koden. Som vist i animationen ovenfor, ændrede identifikatoren for committen på feature/payment-grenen sig efter rebase.

question mark

Hvad er hovedformålet med at bruge git rebase i stedet for git merge?

Select the correct answer

Var alt klart?

Hvordan kan vi forbedre det?

Tak for dine kommentarer!

Sektion 3. Kapitel 4

Spørg AI

expand

Spørg AI

ChatGPT

Spørg om hvad som helst eller prøv et af de foreslåede spørgsmål for at starte vores chat

course content

Kursusindhold

Github-Grundlæggende

Github-Grundlæggende

1. Introduktion til GitHub
2. Grundlæggende Interaktion med Fjernlagre
3. Mere Avancerede Workflows

book
Grundlæggende om Rebase

Oprettelse af et commit på main-grenen

Start med at oprette et commit direkte på den eksterne main-gren ved at redigere README.md-filen i det eksterne repository. Dette vil medføre, at main-grenen og feature/payment-grenen får en afvigende commit-historik.

Her er linjen, der blev tilføjet til filen:

Her er den tilsvarende commit-besked:

Forståelse af rebase

Som nævnt i det forrige kapitel, kan og bør feature-grenen, når den er blevet gennemgået og testet, flettes tilbage i main-grenen. Indtil nu har vi kun brugt kommandoen git merge til dette formål. En anden tilgang er dog at bruge kommandoen git rebase.

Note
Læs mere

Rebase er processen, hvor en sekvens af commits flyttes eller kombineres til et nyt base commit. Dette gøres ved at afspille ændringerne fra én gren over på en anden gren, hvilket resulterer i en lineær commit-historik.

Når vi opretter en gren, holder Git styr på det seneste commit på begge grene. Hvis kun én gren har nye ændringer, kan Git fast-forwarde og anvende ændringerne. Hvis begge grene har nye ændringer, opretter Git et nyt merge commit, hvilket resulterer i et trevejs-merge.

Her er et eksempel på, hvordan et trevejs-merge ville se ud i vores tilfælde, hvor C4 var det seneste commit på feature/payment-grenen før sammenfletning:

Dog trevejssammenfletninger kan gøre fejlfinding mere kompleks på grund af den opdelte, ikke-lineære historik. Ved at rebase ændrer vi udgangspunktet for vores commits og afspiller dem oven på det nye udgangspunkt, hvilket gør det muligt for Git at udføre en fast-forward-sammenfletning og opretholde en lineær historik.

Her er en animation, der illustrerer, hvordan rebase kan udføres i vores tilfælde (commit-identifikatorerne svarer ikke til de reelle her):

Note
Bemærk

Når du rebaser en gren, omskriver du i bund og grund dens historik. Det betyder, at de gamle commits erstattes med nye, som har forskellige identifikatorer (hash-summer), fordi de er baseret på forskellige snapshots af koden. Som vist i animationen ovenfor, ændrede identifikatoren for committen på feature/payment-grenen sig efter rebase.

question mark

Hvad er hovedformålet med at bruge git rebase i stedet for git merge?

Select the correct answer

Var alt klart?

Hvordan kan vi forbedre det?

Tak for dine kommentarer!

Sektion 3. Kapitel 4
some-alt