Articles

Hva er en lineær git-historie

Hvis du noen gang har vært i den beskyttede greninstallasjonen Av Github, har du sikkert sett det gjennom denne innstillingen.

 github-innstillinger.png

du må spørre meg hva dette er. Faktisk motvirker de fleste av gits arbeidsflyt det, så ingen bør være oppmerksom på det. Men jeg har sett det uansett, så la oss finne ut.

Definer

etter min mening er det bare en forplikte historie uten en sammenslåing. Betydning hver begå har bare 1 forelder og 1 barn. Det vil se ut som en rett linje.

for eksempel som dette

1
2

—o – – – o – – – o – – – o – – – o

Og dette er ikke en lineær historie

1
2
3
4

—o – – – o – – – – O – – – M – – – – o – – – o
/
—x – – – x

Hvordan få en lineær historie

Først av Alt, når har vi sammenslåingen forplikte. Merge commit genereres når vi fusjonerer 2 grener, men kan ikke bruke fast forward-strategien, git vil skape en merge commit for å fusjonere 2 grener. For eksempel har vi 2 grener som dette.

1
2
3
4

master—o—o – – – o
testing A – – – B

Når testing har samme historie som master, med bare 2 flere forpliktelser A og B, kan vi spole fremover . Det betyr at bare gjelder endringer av A og B er gjort.

1
2

master —o—o—o— – a – – – B

Men hvis vi har 2 grener som dette.

1
2
3
4

master—o—o—O—C – – – d
testing A – – – B

da vil du ikke kunne bruke fast forward, du må opprette en fusjonsforpliktelse. Merge 2 gren vil se slik ut.

1
2
3
4

master – – – o – – – o – – – O – – – – C – – – – D – – – M
/
testing A – – – – – – – B

hvis du bruker git merge med flagget --no-ff, selv om grenen kan spole fremover , opprettes det fortsatt en sammenslåing.

1
2
3
4

master – – – o – – – o – – – – o – – – – – – – M—
/
testing A – – – B

Så for å få en lineær historie, må vi sørge for at hver fusjon og gren fusjonert må ha en oppdatert historie med basisgrenen, slik at vi kan bruke fast forward-strategien. For å oppdatere gren med base gren, bruker vi git rebase . Rebase vil bruke alle innlegginger av gjeldende grenen til basen grenen.

det nåværende greneksemplet er dette. Branch feature sjekket ut fra master på commit A

1
2
3
4

master —A—B—C
funksjon D – – – E

hvis du fusjonerer 2 grener nå, vil du opprette en sammenslåing. Nå fra grenen feature bruker jeg git rebase som dette.

1
2

git rebase master

Det vil være som feature vil bli sjekket ut igjen fra commit C , deretter commit D og E vil bli brukt på nytt til feature. Nå gren vil se slik ut.

1
2
3
4

master —A—B—C
funksjon D – – – E

feature kan nå slås sammen til master med fast forward-strategien.

Merk at rebase vil endre historien som du ser ovenfor. Så du bruker bare rebase på den nåværende grenen du gjør (ikke presset til den generelle repo) bare. Hvis du jobber med en stor, tidkrevende funksjon (arbeider alene, ikke del en gren med noen), vil regelmessig rebasing med basegrenen hjelpe kodeoppdateringen med den nyeste koden fra basegrenen, og det er på tide å slå sammen. feature konflikt samt bugs ennå ikke oppdaget.

Lineær historie for hva

Så hvorfor vil folk ha en lineær historie. Det er flere fordeler som følger

  • enkelt bestemme rekkefølgen på forpliktelser. Du vet sikkert allerede at merge forplikter faktisk kombinere to grener og hver gren kan ha historie uavhengig av hverandre. Når du bruker git log , ser du at innleggene er organisert som en rett linje. Men faktisk er det så lett å lese. Og faktisk ser det ut som bildet ovenfor. Så det er vanskelig å avgjøre hvilken som er først, og det er vanskelig å vite hvilken forpliktelse som faktisk forårsaket en feil.
  • Forplikte historien mer ryddig. Det blir ingen sammenslåing som vil forvirre deg lenger. Og du prøver å kjøre git log --graph med en repo uten en lineær historie, vil forstå dette.
  • enkelt gå tilbake begå. Fordi hver commit har bare 1 forelder, i motsetning til merge commits, revert commits eller cherry-picks er mye mindre hodepine.

Defekt:

  • trenger brukere å forstå git. git rebase faktisk ganske vanskelig å bruke og gjør en forplikte historie feil enkelt.
  • Løs konflikt med git rebase mye vanskeligere enn git merge. Med merge trenger vi bare å fikse konflikten i en forpliktelse. Mens med rebase, har kanskje hver forpliktelse konflikt.
  • Faktisk trenger Du kanskje ikke en vakker historie. Alle har det bra med git merge .

Krev lineær historie På Github

hvis denne funksjonen er aktivert på Github, vil du ikke kunne slå sammen trekkforespørsler ved å opprette fletteinnlegg lenger.

github-merge-lineær.png

du har bare 2 alternativer igjen: Squash og merge og Rebase og merge . Squash og merge vil squash alle forpliktelser i trekk forespørsler, rebase og merge. Rebase og merge er nesten rebase vi ser ovenfor. Begge bruker fast forward-strategien for ikke å skape flere sammenslåinger og holde commit-historien lineær.

hvis Du fusjonerer Med Rebase og merge, så når du går TILBAKE TIL PR, Vil Github gjøre hver commit I PR en revert commit i stedet for bare en commit så stor som merge commit.

github-tilbakestill-rebase.png

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.