de Fleste integrationer ske med en sammenfletning, men til tider en udvikler ønsker at få deres lokale kode fanget op med master-branch gennem en rebase i stedet. I dette eksempel vil vi demonstrere, hvordan man git rebase en gren til master i stedet for at bruge merge-kommandoen, samtidig med at man påpeger virkningen af at udføre en git rebase til master operation.
Hvad betyder Git rebase til master?,
i denne tutorial tager vi den gren, der hedder develop og rebase den på spidsen af master.
udviklingsgrenen brød ud fra master ved commit C, så begge grene deler filerne a.html, b.html og c.html. Se billedet nedenfor for at hjælpe med at visualisere dette.
siden filialen opstod, har master tilføjet commits D og E. Dette betyder, at master har to filer, der udvikler, ikke har, nemlig d.html og e.html.,
Dette er, hvordan Git repository ser ud inden et git-rebase at mestre.
desuden har der siden opdelingen været to nye forpligtelser i udviklingsgrenen og tilføjet filerne f.html og g.html. Dette er filer, som udviklingsgrenen har, som mastergrenen ikke gør.
Dette er, hvordan GitLab repository ser efter git rebase at mestre.,
Virkningen af Git-rebase
Efter en vellykket udvikle gren til master rebase:
- filer i master-branch vil ikke ændre
- at udvikle filialen vil desuden tilegne sig alle de master-branch ‘s nye filer
- udvikle stream’ s filial punkt vil ændre sig.
- det vil se ud som om udvikle gren split efter begå E på master gren.
- før rebasen splittede udviklingsgrenen fra master ved commit C.,
Git rebase til master command syntaks
handlingen til at udføre en Git rebase til master er ligetil. Du skal blot tilføje til slutningen af kommandoen navnet på kildegrenen og derefter navnet på den gren, der skal rebase. At rebase udvikle sig til master kommandoen er som følger:
git rebase master develop
Advarsel: Der er et git-rebase på switch, som nogle gange udviklere fejlagtigt at tro, de har brug for, at der med den rebase kommando. Dette vil medføre, at forpligtelser bliver discared og filer går tabt., Gør ikke fejlen ved at udføre en git rebase på drift.
før rebase havde udviklingsgrenen kun fem filer.
Hver gren har fem filer, før git-rebase at mestre drift.
efter Git rebase til master, har udviklingsgrenen syv filer. Det har bevaret alle sine originale filer og erhvervet to nye filer fra spidsen af master gren., Antallet af filer i hovedgrenen forbliver dog uændret.
Efter git rebase af at udvikle master, udvikle gren overtager alle master-filer.
det faktum, at mastergrenen ikke erhvervede nogen filer fra udviklingsgrenen, kaster ofte nye Git-brugere væk, men dette er den forventede opførsel. En git rebase synkroniserer ikke mellem grene. Det fanger simpelthen en gren op med de seneste ændringer fra en anden.,
antallet af filer i at udvikle stigning efter git rebase at mestre.
fortsæt med forsigtighed
Når der opstår en Git-rebase, ændres depotets commit-historie uopretteligt. Efter rebase i vores eksempel tildeles commits F og G helt nye commit id ‘er, og de gamle commit id’ er kasseres. Af denne grund vil du ofte se rebased commits markeret som f ‘og G’ for at understrege, at nye commit id ‘ er er blevet tildelt.,
Hvis du rebase en filial, der er delt med en anden udvikler og skubbe dine ændringer tilbage til GitHub eller GitLab, en fyr der udvikler vil løbe ind i en række forskellige problemer, når de forsøger at trække den omgjort lageret i deres lokale udviklingsmiljø. Commits de har lokalt vil være forsvundet på fjernbetjeningen, og den eksterne gren vil have en inkompatibel gren historie. Som du kunne forestille dig, kan rebasing en delt gren eller S .uashing Git forpligter anrette havok.,
Rebase til GitHub eller GitLab
faktisk, hvis du rebase og forsøger at skubbe til GitLab eller GitHub, tillader serveren ikke, at handlingen udføres. For at rebase til GitHub eller GitLab skal en udvikler tilføje-force-kontakten til Git push-kommandoen for at tvinge ændringerne til at blive accepteret.
git push origin --force
En GitLab eller GitHub rebase tryk, vil den blive afvist, medmindre det tvinges.,
den accepterede logik er kun at git rebase for at mestre filialer lokale til dit personlige arbejdsområde. På den måde påvirker dine Git-oprydningskommandoer ikke nogen anden. Udfør ikke en git rebase for at mestre på filialer, der deles med andre udviklere. En rebase på master er fint, bare ikke omvendt. Ellers vil du sandsynligvis bryde build og push eller pull operationer vil blive sat på standby, modarbejde fortsat udvikling og gøre dig persona non grata med resten af udviklere og DevOps team.