Profesjonell arbeidsflyt med Git og GitHub · leksjon

Rebasing kontra merging

Sammenlign rebasing og merging, og lær når du bør bruke hver av dem for å få en ryddig og lineær historikk.

Leksjon 3 av 411 trinn

Rebasing kontra merging er en gratis leksjon i Profesjonell arbeidsflyt med Git og GitHub på CoddyKit. Dette er leksjon 3 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Profesjonell arbeidsflyt med Git og GitHub, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Profesjonell arbeidsflyt med Git og GitHub inneholder totalt 4 leksjoner.

Merge eller rebase? Valget

Når du arbeider med Git, opplever du ofte at grenen din avviker fra en annen gren, for eksempel at feature-grenen avviker fra main.

Hvordan samler du disse endringene? Git tilbyr to hovedstrategier: merge og rebase. Begge oppnår integrasjon, men de gjør det på fundamentalt forskjellige måter, noe som fører til ulik prosjektlogg.

Merge: Slå sammen historikk

Merge er Gits standardmåte å integrere endringer på. Når du merger én gren inn i en annen, tar Git innholdet fra kildegrenen og kombinerer det med målgrenen.

Det viktigste kjennetegnet ved en merge er at den oppretter en ny merge-commit. Denne commiten har to foreldrecommiter og viser uttrykkelig at to avvikende historikker er slått sammen. Den bevarer den nøyaktige historikken til begge grenene.

Utføre en Git-merge

La oss se på en enkel merge. Vi oppretter en feature-gren, legger til en commit og merger den deretter tilbake inn i main.

git init my_merge_project
cd my_merge_project
echo "Initial content" > file.txt
git add .
git commit -m "Initial commit"

git branch feature
git checkout feature
echo "Feature A" >> feature.txt
git add .
git commit -m "Add feature A"

git checkout main
echo "Main update" >> main.txt
git add .
git commit -m "Update main"

git merge feature

git log --oneline --graph

Merge: Fordeler og ulemper

Merge er enkelt og trygt for delte grener, men kan føre til en «rotete» historikk.

Fordeler:
Bevarer den nøyaktige historikken til commitene.
Er ikke-destruktiv og skriver ikke om eksisterende commiter.
Er enkel å bruke og forstå.
Ulemper:
Kan opprette en «støyende» historikk med mange merge-commiter.
Grafen kan se kompleks ut når mange grener flettes sammen.

Rebase: Skrive om historikken

Rebase er et alternativ til merge som integrerer endringer ved å flytte eller kombinere en rekke commiter til en ny basiskommit. I stedet for å opprette en merge-commit skriver den om prosjektets historikk.

I praksis blir commitene på feature-grenen din «spilt av på nytt» oppå den nyeste commiten i målgrenen, slik at det ser ut som om du startet arbeidet derfra. Dette oppretter en lineær historikk uten ekstra merge-commiter.

Utføre en Git-rebase

La oss nå prøve det samme scenarioet med rebase. Vi rebaser feature-grenen vår oppå main.

Legg merke til hvordan commiten på feature-grenen brukes på nytt oppå den nyeste commiten i main, og deretter gjør en fast-forward-merge at main peker på den.

git init my_rebase_project
cd my_rebase_project
echo "Initial content" > file.txt
git add .
git commit -m "Initial commit"

git branch feature
git checkout feature
echo "Feature B" >> feature.txt
git add .
git commit -m "Add feature B"

git checkout main
echo "Main update 2" >> main.txt
git add .
git commit -m "Update main 2"

git checkout feature
git rebase main

git checkout main
git merge feature

git log --oneline --graph

Rebase: Fordeler og ulemper

Rebase oppretter en ryddig historikk, men medfører en viktig advarsel når det gjelder delte grener.

Fordeler:
Oppretter en ryddig, lineær prosjekthistorikk.
Gjør commit-historikken enklere å navigere i og forstå.
Lar deg rydde opp i commiter (slå sammen, endre rekkefølge) før integrering.
Ulemper:
Skriver om commit-historikken.
Kan være risikabelt hvis det brukes på commiter som allerede er pushet til et delt (offentlig) remote-repositorium.

Merge kontra rebase: Sammenligning

Her er en rask oppsummering av de viktigste forskjellene:

Merge:
Oppretter en ny merge-commit.
Bevarer hele den nøyaktige historikken.
Er ikke-destruktiv.
Grafen kan bli kompleks.
Rebase:
Skriver om historikken uten en merge-commit.
Resulterer i en lineær historikk.
Er destruktiv (endrer commit-ID-er).
Grafen er svært ryddig.

Velge strategi

Så når bør du bruke hva?

Bruk merge når:
Du arbeider på offentlige/delte grener (for eksempel main, develop).
Du må bevare den nøyaktige historikken til prosjektet.
Du vil vise uttrykkelig når avvikende historikker ble slått sammen.
Bruk rebase når:
Du arbeider på din private feature-gren før du pusher den.
Du ønsker en ryddig, lineær historikk.
Du vil rydde opp i commitene på feature-grenen (for eksempel slå dem sammen eller endre rekkefølgen) før integrering.

Den gylne regelen: Rebaser aldri commiter som allerede er pushet til et delt remote-repositorium! Rebase av delt historikk kan skape store problemer for samarbeidspartnerne dine.

Rask kontroll: Merge eller rebase?

Vurder egenskapene til Gits to hovedstrategier for integrasjon.

Besvar den i den interaktive leksjonen

Oppsummering: Merge kontra rebase

I denne leksjonen har vi utforsket Gits to grunnleggende måter å integrere endringer på: merge og rebase.

Merge kombinerer historikker med en ny merge-commit og bevarer alle opprinnelige commiter.
Rebase skriver om historikken og oppretter en lineær flyt ved å flytte commiter.

Velg med omhu basert på teamets arbeidsflyt, og husk den gylne regelen: Rebaser aldri offentlig historikk! Denne forståelsen er avgjørende for å opprettholde en ryddig og samarbeidsvennlig Git-arbeidsflyt.

Gratis å komme i gang

Lær deg Profesjonell arbeidsflyt med Git og GitHub med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 12
Leksjoner: 48

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Rebasing kontra merging» gratis?

Ja – hele teksten i «Rebasing kontra merging» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Profesjonell arbeidsflyt med Git og GitHub-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Profesjonell arbeidsflyt med Git og GitHub inneholder totalt 4 leksjoner.

Hva lærer jeg i «Rebasing kontra merging»?

Sammenlign rebasing og merging, og lær når du bør bruke hver av dem for å få en ryddig og lineær historikk. Du øver på Profesjonell arbeidsflyt med Git og GitHub med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Profesjonell arbeidsflyt med Git og GitHub?

Ingen tidligere erfaring er nødvendig. Profesjonell arbeidsflyt med Git og GitHub på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 3 av 4.

Hvor lang tid tar leksjonen «Rebasing kontra merging»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Profesjonell arbeidsflyt med Git og GitHub-leksjonen?

Ja. Alle Profesjonell arbeidsflyt med Git og GitHub-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

← Tilbake til Profesjonell arbeidsflyt med Git og GitHub