En introduktion til Git fusion og rebase: hvad de er, og hvordan man bruger dem

Som udvikler skal mange af os vælge mellem Flet og Rebase. Med alle de referencer, vi får fra internettet, tror alle "Brug ikke Rebase, det kan forårsage alvorlige problemer." Her vil jeg forklare, hvad fletning og rebase er, hvorfor du skal (og ikke bør) bruge dem, og hvordan man gør det.

Git Merge og Git Rebase tjener det samme formål. De er designet til at integrere ændringer fra flere grene i en. Selvom det endelige mål er det samme, opnår disse to metoder det på forskellige måder, og det er nyttigt at kende forskellen, når du bliver en bedre softwareudvikler.

Dette spørgsmål har splittet Git-samfundet. Nogle mener, at du altid skal omlægge, og andre, at du altid skal fusionere. Hver side har nogle overbevisende fordele.

Git Merge

Fletning er en almindelig praksis for udviklere, der bruger versionskontrolsystemer. Uanset om der oprettes filialer til test, fejlrettelser eller andre grunde, forpligter fletning ændringer til et andet sted. For at være mere specifik tager fletning indholdet af en kildegren og integrerer dem med en målgren. I denne proces ændres kun målgrenen. Kildegrenens historie forbliver den samme.

Fordele

  • Enkel og velkendt
  • Bevarer komplet historie og kronologisk rækkefølge
  • Vedligeholder filialens kontekst

Ulemper

  • Forpligtelseshistorik kan blive forurenet af masser af fusionsforpligtelser
  • Fejlfinding ved hjælp af git bisectkan blive sværere

Hvordan gør man det

Flet master gren ind i funktionen gren ved hjælp af checkoutog mergekommandoer.

$ git checkout feature $ git merge master (or) $ git merge master feature

Dette vil skabe et nyt " Merge commit " i funktionsgrenen, der holder historien for begge grene.

Git Rebase

Rebase er en anden måde at integrere ændringer fra en gren til en anden. Rebase komprimerer alle ændringerne til et enkelt "patch". Derefter integrerer det plasteret på målgrenen.

I modsætning til sammenfletning flader fortabning historien, fordi den overfører det færdige arbejde fra en gren til en anden. I processen elimineres uønsket historie.

Rebases er, hvordan ændringer skal passere fra toppen af ​​hierarkiet og nedad, og fletninger er, hvordan de strømmer tilbage opad

Fordele

  • Strømliner en potentielt kompleks historie
  • Det er nemt at manipulere en enkelt forpligtelse (f.eks. Tilbageføre dem)
  • Undgår fusion begå "støj" i travle repos med travle grene
  • Renser mellemliggende forpligtelser ved at give dem en enkelt forpligtelse, hvilket kan være nyttigt for DevOps-hold

Ulemper

  • Squashing af funktionen ned til en håndfuld forpligtelser kan skjule konteksten
  • Omfordeling af offentlige opbevaringssteder kan være farligt, når du arbejder som et team
  • Det er mere arbejde: Brug rebase til altid at holde din funktionsgren opdateret
  • Omfordeling med fjerntliggende grene kræver, at du tvinger push. Det største problem, folk står overfor, er at de tvinger push, men ikke har indstillet git push-standard. Dette resulterer i opdateringer til alle filialer med samme navn, både lokalt og eksternt, og det er forfærdeligt at håndtere.
Hvis du rebase forkert og utilsigtet omskriver historikken, kan det føre til alvorlige problemer, så sørg for at vide, hvad du laver!

Hvordan gør man det

Sæt funktionsgrenen om på hovedgrenen ved hjælp af følgende kommandoer.

$ git checkout feature $ git rebase master

Dette flytter hele funktionsgrenen oven på mastergrenen. Det gør det ved at omskrive projekthistorikken ved at oprette helt nye forpligtelser for hver forpligtelse i den originale (funktions) gren.

Interaktiv rebasing

Dette gør det muligt at ændre forpligtelserne, når de flyttes til den nye gren. Dette er mere kraftfuldt end automatisk rebase, da det giver fuld kontrol over filialens forpligtelseshistorik. Typisk bruges dette til at rydde op i en rodet historie, før en sammensætning af en funktionsgren til master.

$ git checkout feature $ git rebase -i master

Dette åbner redaktøren ved at angive alle de forpligtelser, der skal flyttes.

pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3

Dette definerer nøjagtigt, hvordan grenen vil se ud, efter at rebasen er udført. Ved at ombestille enhederne kan du få historien til at ligne det, du vil have. For eksempel kan du bruge kommandoer som fixup, squash, editosv, i stedet for pick.

Hvilken der skal bruges

Så hvad er bedst? Hvad anbefaler eksperterne?

Det er svært at generalisere og beslutte det ene eller det andet, da hvert hold er forskelligt. Men vi er nødt til at starte et sted.

Hold skal overveje flere spørgsmål, når de indstiller deres Git rebase vs. fletningspolitikker. For som det viser sig, er den ene workflowstrategi ikke bedre end den anden. Det afhænger af dit team.

Overvej niveauet for rebasing og Git-kompetence på tværs af din organisation. Bestem, i hvor høj grad du sætter pris på enkeltheden ved rebasing sammenlignet med sporbarhed og historik ved fletning.

Endelig skal beslutninger om sammenlægning og omlægning overvejes i sammenhæng med en klar forgreningsstrategi ( Se denne artikel for at forstå mere om forgreningsstrategi). En vellykket forgreningsstrategi er designet omkring organisationen af ​​dine teams.

Hvad anbefaler jeg?

Efterhånden som teamet vokser, bliver det svært at styre eller spore udviklingsændringer med en altid fusioneret politik. At have en ren og forståelig begivenhedshistorik er brug af Rebase rimelig og effektiv.

Ved at overveje følgende omstændigheder og retningslinjer kan du få det bedste ud af Rebase:

  • Du udvikler dig lokalt: Hvis du ikke har delt dit arbejde med nogen anden. På dette tidspunkt foretrækker du at rebase frem for fletning for at holde din historie ryddet. Hvis du har din personlige fork af arkivet, og den ikke deles med andre udviklere, er du sikker på at rebase, selv efter at du er skubbet til din gren.
  • Din kode er klar til gennemgang: Du oprettede en pull-anmodning. Andre gennemgår dit arbejde og henter det muligvis i deres gaffel til lokal gennemgang. På dette tidspunkt skal du ikke omlægge dit arbejde. Du skal oprette 'rework' -forpligtelser og opdatere din funktionsgren. Dette hjælper med sporbarhed i trækanmodningen og forhindrer utilsigtet brud på historikken.
  • Gennemgangen er færdig og klar til at blive integreret i målgrenen. Tillykke! Du er ved at slette din funktionsgren. I betragtning af at andre udviklere ikke henter sammen i disse ændringer fra dette tidspunkt, er dette din chance for at desinficere din historie. På dette tidspunkt kan du omskrive historik og folde de oprindelige forpligtelser og de irriterende 'forarbejder' og 'flette' forpligtelser til et lille sæt fokuserede forpligtelser. Oprettelse af en eksplicit fletning for disse forpligtelser er valgfri, men har værdi. Den registrerer, hvornår funktionen er færdig med at mestre.

Konklusion

Jeg håber, at denne forklaring har givet noget indblik i Git-fusion og Git-rebase. Flette vs rebase-strategi kan altid diskuteres. Men måske hjælper denne artikel med at fjerne din tvivl og give dig mulighed for at vælge en tilgang, der fungerer for dit team.

Jeg ser frem til at skrive om Git-arbejdsgange og koncepter for Git . Kommenter de emner, som du vil have mig til at skrive om næste gang. Skål!

code = coffee + developer

kodeskole til softwareudviklere