DevOps-bootcamp · 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 DevOps-bootcamp på CoddyKit. Dette er leksjon 3 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i DevOps-bootcamp, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i DevOps-bootcamp 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.

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 DevOps-bootcamp 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
142
Leksjoner
568

Ofte stilte spørsmål

Er leksjonen «Rebasing kontra merging» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien DevOps-bootcamp, inkludert «Rebasing kontra merging», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i DevOps-bootcamp 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å DevOps-bootcamp 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 DevOps-bootcamp?

Ingen tidligere erfaring er nødvendig. DevOps-bootcamp 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 DevOps-bootcamp-leksjonen?

Ja. Alle DevOps-bootcamp-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

  1. Arbeidsflyt med feature-brancher
  2. Introduksjon til Gitflow-arbeidsflyt
  3. Rebasing kontra merging
  4. Trunk-basert utvikling
← Tilbake til DevOps-bootcamp