Sissejuhatus Giti ühendamisse ja uuesti alustamisse: mis need on ja kuidas neid kasutada

Arendajana peavad paljud meist valima Merge ja Rebase vahel. Kõigi internetist saadud viidete põhjal usuvad kõik: "Ärge kasutage Rebase'i, see võib põhjustada tõsiseid probleeme." Siinkohal selgitan, mis on ühendamine ja uuesti alustamine, miks peaksite (ja ei peaks) neid kasutama ja kuidas seda teha.

Git Merge ja Git Rebase teenivad sama eesmärki. Need on loodud mitme haru muudatuste integreerimiseks ühte. Kuigi lõppeesmärk on sama, saavutavad need kaks meetodit selle erineval viisil ja on kasulik teada erinevust, kui saate paremaks tarkvaraarendajaks.

See küsimus on Giti kogukonna lõhestanud. Mõned usuvad, et peate alati uuesti hindama, ja teised, et peate alati ühendama. Mõlemal poolel on mõned veenvad eelised.

Git Merge

Ühinemine on versioonikontrollisüsteeme kasutavate arendajate tavaline tava. Sõltumata sellest, kas harud on loodud testimiseks, veaparandusteks või muudel põhjustel, ühendamine muudab muudatused teise asukohta. Täpsemalt öeldes võtab ühendamine allikaharu sisu ja integreerib selle sihthargiga. Selles protsessis muudetakse ainult sihtharu. Allikaharu ajalugu jääb samaks.

Plussid

  • Lihtne ja tuttav
  • Säilitab täieliku ajaloo ja kronoloogilise järjekorra
  • Säilitab haru konteksti

Miinused

  • Kohustuste ajalugu võib saastuda paljude liitmiskohustuste abil
  • Kasutamise abil silumine git bisectvõib muutuda raskemaks

Kuidas seda teha

Ühendage põhiharu funktsiooniharuga käsude checkoutja mergeabil.

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

Nii luuakse funktsioonide harusse uus ühendamise kohustus, mis hoiab mõlema haru ajalugu.

Git Rebase

Rebase on veel üks võimalus integreerida muudatusi ühest harust teise. Rebase tihendab kõik muudatused üheks plaastriks. Seejärel integreerib see plaastri haru sihtmärgiks.

Erinevalt ühinemisest tasandab taaskasutamine ajalugu, sest see kannab valminud töö ühest harust teise. Selle käigus elimineeritakse soovimatu ajalugu.

Uuendusbaasid on see, kuidas muudatused peaksid hierarhia tipust allapoole liikuma, ja ühinemised on see, kuidas need liiguvad tagasi ülespoole

Plussid

  • Sujuvamaks potentsiaalselt keerukat ajalugu
  • Ühe pühendumisega manipuleerimine on lihtne (nt nende taastamine)
  • Väldib hõivatud oksade ühendamist hõivatud repodega
  • Puhastab keskmised kohustused, tehes neist ühe kohustuse, mis võib DevOpsi meeskondadele abiks olla

Miinused

  • Funktsiooni jaotamine käputäie toiminguteni võib konteksti varjata
  • Avalike hoidlate ümberhindamine võib meeskonnana töötades olla ohtlik
  • See on rohkem tööd: rebase'i abil saate oma funktsiooniharu alati värskendada
  • Kaugete harudega taaskäivitamine nõuab surumist. Suurim probleem, millega inimesed silmitsi seisavad, on see, et nad sunnivad surumist, kuid pole vaikeseadeks seadnud git pushi. Selle tulemusel värskendatakse kõiki filiaale, millel on sama nimi, nii lokaalselt kui ka kaugelt, ja sellega on kohutav tegeleda.
Kui määrate valesti ümber ja kirjutate ajalugu tahtmatult ümber, võib see põhjustada tõsiseid probleeme, nii et veenduge, et teate, mida teete!

Kuidas seda teha

Alustage funktsiooniharu põhiharule järgmiste käskude abil.

$ git checkout feature $ git rebase master

See liigutab kogu funktsiooniharu peaharu kohale. Ta teeb seda, kirjutades projekti ajaloo ümber, luues igale algse (funktsiooni) haru jaoks täiesti uued kohustused.

Interaktiivne taaskäivitamine

See võimaldab muuta kulukohustusi, kui need uude harusse viiakse. See on võimsam kui automaatne taaskäivitamine, kuna see pakub täielikku kontrolli haru pühendumisajaloo üle. Tavaliselt kasutatakse seda räpase ajaloo puhastamiseks enne funktsiooni haru masteriks ühendamist.

$ git checkout feature $ git rebase -i master

See avab redaktori, loetledes kõik ümberpaigutatavad toimingud.

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

See määratleb täpselt, milline haru välja näeb pärast taaskäivitamist. Olemite ümberkorraldamise abil saate ajaloo välja näha nagu iganes soovite. Näiteks saate kasutada käskude nagu fixup, squash, editjne, asemel pick.

Millist neist kasutada

Mis on parim? Mida soovitavad eksperdid?

Üht või teist on raske üldistada ja otsustada, sest iga meeskond on erinev. Kuid me peame kuskilt alustama.

Võistkonnad peavad oma Giti taaskasutamise ja ühendamise eeskirjade määramisel arvestama mitme küsimusega. Sest nagu selgub, pole üks töövoo strateegia parem kui teine. See sõltub teie meeskonnast.

Mõelge oma organisatsiooni ümberpaigutamise tasemele ja Giti kompetentsile. Tehke kindlaks, millises ulatuses hindate uuesti alustamise lihtsust võrreldes ühendamise jälgitavuse ja ajalooga.

Lõpuks tuleks ühinemise ja ümberpaigutamise otsuseid kaaluda selge hargnemisstrateegia kontekstis (hargnemisstrateegia kohta lisateabe saamiseks vaadake seda artiklit ). Edukas hargnemisstrateegia on välja töötatud teie meeskondade organisatsiooni ümber.

Mida ma soovitan?

Kui meeskond kasvab, on alati keeruline ühendada või jälgida arengumuudatusi alati ühendatava poliitikaga. Puhta ja arusaadava pühendumisajaloo saamiseks on Rebase'i kasutamine mõistlik ja tõhus.

Arvestades järgmisi asjaolusid ja juhiseid, saate Rebasest parimat :

  • Arendate kohapeal: kui te pole oma tööd kellegagi teisega jaganud. Siinkohal peaksite oma ajaloo korrastamiseks eelistama ühendamist uuesti ühendamise asemel. Kui teil on oma isiklik hoidla kahvel ja seda ei jagata teiste arendajatega, on teil turvaline taaskäivitada ka siis, kui olete oma haru juurde jõudnud.
  • Teie kood on ülevaatamiseks valmis: lõite tõmbetaotluse. Teised vaatavad teie tööd üle ja toovad selle kohalikult ülevaatuseks oma kahvlisse. Siinkohal ei peaks te oma tööd ümber hindama. Peaksite looma ümbertöötamiskohustused ja värskendama oma funktsiooniharu. See aitab tõmmataotluses jälgitavust ja hoiab ära juhusliku ajaloo purunemise.
  • Ülevaade on tehtud ja valmis sihtharusse integreerimiseks. Palju õnne! Kustutate oma funktsiooniharu. Arvestades, et teised arendajad ei hakka neid muudatusi sellest hetkest alates tõmbama-ühendama, on see teie võimalus oma ajalugu puhastada. Siinkohal saate ajaloo ümber kirjutada ja algsed kohustused kokku klappida ning need tüütud 'pr rework' ja 'sulatada' kohustused väikesteks fokuseeritud toiminguteks. Nende toimingute jaoks selgesõnalise ühendamise loomine on valikuline, kuid sellel on väärtus. See salvestab, kui funktsioon on meistriks saanud.

Järeldus

Loodan, et see selgitus on andnud mõningaid teadmisi Git-i ühendamise ja Git-i ümberpaigutamise kohta. Ühendamise vs uuesti alustamise strateegia on alati vaieldav. Kuid võib-olla aitab see artikkel teie kahtlusi hajutada ja võimaldab teil läheneda oma meeskonnale sobivale lähenemisviisile.

Ootan põnevusega kirjutamist Giti töövoogudest ja Giti kontseptsioonidest . Kommenteerige teemasid, millest soovite, et ma järgmisena kirjutaksin. Terviseks!

code = coffee + developer

tarkvaraarendajate kodeerimiskool