Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Lære Grunnleggende om Rebase | Mer Avanserte Arbeidsflyter
GitHub-Grunnleggende
course content

Kursinnhold

GitHub-Grunnleggende

GitHub-Grunnleggende

1. Introduksjon til GitHub
2. Grunnleggende Samhandling med Eksterne Lagre
3. Mer Avanserte Arbeidsflyter

book
Grunnleggende om Rebase

Lage en commit på main-grenen

Start med å lage en commit direkte på den eksterne main-grenen ved å redigere README.md-filen i det eksterne depotet. Dette vil føre til at main-grenen og feature/payment-grenen får en avvikende commit-historikk.

Her er linjen som ble lagt til i filen:

Her er den tilhørende commit-meldingen:

Forståelse av rebase

Som nevnt i forrige kapittel, når feature-grenen er gjennomgått og testet, kan og bør den flettes tilbake til main-grenen. Til nå har vi kun brukt kommandoen git merge for dette formålet. En annen tilnærming er imidlertid å bruke kommandoen git rebase.

Note
Les mer

Rebase er prosessen med å flytte eller kombinere en sekvens av commits til en ny base commit. Dette gjøres ved å spille av endringene fra én gren over på en annen gren, noe som resulterer i en lineær commit-historikk.

Når vi oppretter en gren, sporer Git siste commit på begge grenene. Hvis kun én gren har nye endringer, kan Git hurtigspole og bruke endringene. Men hvis begge grenene har nye endringer, oppretter Git en ny flette-commit, noe som resulterer i en treveisfletting.

Slik vil en treveisfletting se ut i vårt tilfelle, der C4 var siste commit på feature/payment-grenen før fletting:

Imidlertid kan treveis-flettinger gjøre feilsøking mer komplisert på grunn av delt, ikke-lineær historikk. Ved å rebase endrer vi basen for våre commits og spiller dem av på toppen av den nye basen, noe som lar Git utføre en fast-forward-fletting og opprettholde en lineær historikk.

Her er en animasjon som illustrerer hvordan rebase kan utføres i vårt tilfelle (commit-identifikatorene tilsvarer ikke de virkelige her):

Note
Merk

Når du rebaser en gren, skriver du i praksis om historikken. Dette betyr at de gamle commitene erstattes med nye, som har forskjellige identifikatorer (hash-summer) fordi de er basert på ulike øyeblikksbilder av koden. Som vist i animasjonen over, endret identifikatoren til commit-en på feature/payment-grenen seg etter rebase.

question mark

Hva er hovedformålet med å bruke git rebase i stedet for git merge?

Select the correct answer

Alt var klart?

Hvordan kan vi forbedre det?

Takk for tilbakemeldingene dine!

Seksjon 3. Kapittel 4

Spør AI

expand

Spør AI

ChatGPT

Spør om hva du vil, eller prøv ett av de foreslåtte spørsmålene for å starte chatten vår

course content

Kursinnhold

GitHub-Grunnleggende

GitHub-Grunnleggende

1. Introduksjon til GitHub
2. Grunnleggende Samhandling med Eksterne Lagre
3. Mer Avanserte Arbeidsflyter

book
Grunnleggende om Rebase

Lage en commit på main-grenen

Start med å lage en commit direkte på den eksterne main-grenen ved å redigere README.md-filen i det eksterne depotet. Dette vil føre til at main-grenen og feature/payment-grenen får en avvikende commit-historikk.

Her er linjen som ble lagt til i filen:

Her er den tilhørende commit-meldingen:

Forståelse av rebase

Som nevnt i forrige kapittel, når feature-grenen er gjennomgått og testet, kan og bør den flettes tilbake til main-grenen. Til nå har vi kun brukt kommandoen git merge for dette formålet. En annen tilnærming er imidlertid å bruke kommandoen git rebase.

Note
Les mer

Rebase er prosessen med å flytte eller kombinere en sekvens av commits til en ny base commit. Dette gjøres ved å spille av endringene fra én gren over på en annen gren, noe som resulterer i en lineær commit-historikk.

Når vi oppretter en gren, sporer Git siste commit på begge grenene. Hvis kun én gren har nye endringer, kan Git hurtigspole og bruke endringene. Men hvis begge grenene har nye endringer, oppretter Git en ny flette-commit, noe som resulterer i en treveisfletting.

Slik vil en treveisfletting se ut i vårt tilfelle, der C4 var siste commit på feature/payment-grenen før fletting:

Imidlertid kan treveis-flettinger gjøre feilsøking mer komplisert på grunn av delt, ikke-lineær historikk. Ved å rebase endrer vi basen for våre commits og spiller dem av på toppen av den nye basen, noe som lar Git utføre en fast-forward-fletting og opprettholde en lineær historikk.

Her er en animasjon som illustrerer hvordan rebase kan utføres i vårt tilfelle (commit-identifikatorene tilsvarer ikke de virkelige her):

Note
Merk

Når du rebaser en gren, skriver du i praksis om historikken. Dette betyr at de gamle commitene erstattes med nye, som har forskjellige identifikatorer (hash-summer) fordi de er basert på ulike øyeblikksbilder av koden. Som vist i animasjonen over, endret identifikatoren til commit-en på feature/payment-grenen seg etter rebase.

question mark

Hva er hovedformålet med å bruke git rebase i stedet for git merge?

Select the correct answer

Alt var klart?

Hvordan kan vi forbedre det?

Takk for tilbakemeldingene dine!

Seksjon 3. Kapittel 4
some-alt