Uvod u spajanje i prebazu Gita: što su oni i kako ih koristiti

Kao programeri, mnogi od nas moraju birati između spajanja i ponovnog postavljanja. Uz sve reference koje dobijemo s interneta, svi vjeruju "Ne koristite Rebase, to bi moglo dovesti do ozbiljnih problema." Ovdje ću objasniti što su spajanje i ponovna baza podataka, zašto biste ih trebali (i ne biste trebali) koristiti i kako to učiniti.

Git Merge i Git Rebase imaju istu svrhu. Dizajnirani su za integriranje promjena iz više grana u jednu. Iako je konačni cilj isti, te dvije metode postižu ga na različite načine, a korisno je znati razliku kad postanete bolji programer.

Ovo je pitanje podijelilo zajednicu Git. Neki vjeruju da se uvijek trebate preusmjeriti, a drugi da se uvijek trebate spojiti. Svaka strana ima neke uvjerljive prednosti.

Git Merge

Spajanje je uobičajena praksa za programere koji koriste sustave za kontrolu verzija. Bez obzira jesu li grane stvorene za testiranje, ispravke programskih pogrešaka ili iz drugih razloga, spajanjem se izvršavaju promjene na drugom mjestu. Da budemo precizniji, spajanje uzima sadržaj izvorne grane i integrira ih s ciljnom granom. U ovom se procesu mijenja samo ciljna grana. Povijest izvorne grane ostaje ista.

Pros

  • Jednostavno i poznato
  • Čuva cjelovitu povijest i kronološki poredak
  • Održava kontekst grane

Protiv

  • Povijest urezivanja može postati zagađena mnoštvom obveza spajanja
  • Otklanjanje pogrešaka pomoću git bisectmože postati teže

Kako to učiniti

Spoji glavnu granu u igranom granu s tipkama checkouti mergenaredbe.

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

To će stvoriti novi " Spajanje urezivanja " u grani značajki koja sadrži povijest obje grane.

Git Rebase

Rebase je još jedan način integriranja promjena iz jedne grane u drugu. Rebase komprimira sve promjene u jednu "zakrpu". Zatim integrira zakrpu u ciljnu granu.

Za razliku od spajanja, ponovno zasnivanje poravnava povijest jer prenosi dovršeni posao s jedne grane na drugu. U tom procesu uklanja se neželjena povijest.

Bazi su način na koji bi promjene trebale prolaziti od vrha hijerarhije prema dolje, a spajanja su način na koji teku natrag prema gore

Pros

  • Pojednostavljuje potencijalno složenu povijest
  • Manipuliranje jednim urezivanjem jednostavno je (npr. Vraćanjem u prethodno stanje)
  • Izbjegava spajanje „buke“ spajanja u zauzetim repoima s zauzetim granama
  • Čisti srednje obveze čineći ih jednim urezivanjem, što može biti korisno za DevOps timove

Protiv

  • Smanjivanje značajke na pregršt obveza može sakriti kontekst
  • Ponovno postavljanje javnih spremišta može biti opasno kada radite timski
  • To je više posla: upotreba rebasea kako bi se vaša grana značajki uvijek ažurirala
  • Podmazivanje udaljenim granama zahtijeva prisilno guranje. Najveći problem s kojim se ljudi susreću je prisiljavanje na guranje, ali nisu postavili zadani način git push. To rezultira ažuriranjima svih grana s istim nazivom, i lokalno i udaljeno, i s tim je strašno raditi.
Ako pogrešno prebacujete bazu podataka i nenamjerno prepišete povijest, to može dovesti do ozbiljnih problema, zato budite sigurni da znate što radite!

Kako to učiniti

Vratite granu značajke na glavnu granu pomoću sljedećih naredbi.

$ git checkout feature $ git rebase master

Ovo premješta cijelu granu značajke na vrh glavne grane. To čini ponovnim upisivanjem povijesti projekta stvaranjem potpuno novih predavanja za svako urezivanje u izvornoj grani (značajka).

Interaktivno prenamjenjivanje

To omogućuje izmjene predavanja prilikom premještanja u novu granu. Ovo je moćnije od automatizirane baze podataka, jer nudi potpunu kontrolu nad poviješću urezivanja podružnice. To se obično koristi za čišćenje neuredne povijesti prije spajanja grane značajke u master.

$ git checkout feature $ git rebase -i master

Ovo će otvoriti uređivač popisom svih obveza koje će se premjestiti.

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

Ovo točno definira kako će grana izgledati nakon što se izvrši ponovna baza podataka. Preuređivanjem entiteta možete učiniti da povijest izgleda onako kako želite. Na primjer, možete koristiti naredbe kao što su fixup, squash, edititd, umjesto pick.

Koji koristiti

Pa što je najbolje? Što stručnjaci preporučuju?

Teško je generalizirati i odlučiti se za jedno ili drugo, jer je svaka momčad drugačija. Ali moramo negdje početi.

Timovi moraju razmotriti nekoliko pitanja prilikom postavljanja svojih Git rebase vs. merge pravila. Jer kako se pokazalo, jedna strategija tijeka rada nije bolja od druge. Ovisi o vašem timu.

Razmotrite razinu ponovne osnove i Git kompetencije u vašoj organizaciji. Utvrdite stupanj u kojem cijenite jednostavnost ponovnog podnošenja u usporedbi s sljedivošću i poviješću spajanja.

Konačno, odluke o spajanju i ponovnom postavljanju baze podataka treba razmotriti u kontekstu jasne strategije grananja ( pogledajte ovaj članak da biste razumjeli više o strategiji grananja). Uspješna strategija grananja osmišljena je oko organizacije vaših timova.

Što preporučujem?

Kako tim raste, postat će teško upravljati ili pratiti razvojne promjene uz uvijek politiku spajanja. Da biste imali čistu i razumljivu povijest predavanja, korištenje Rebasea je razumno i učinkovito.

Uzimajući u obzir sljedeće okolnosti i smjernice, možete najbolje iskoristiti Rebase:

  • Lokalno se razvijate: ako svoj rad niste podijelili ni s kim drugim. U ovom trenutku trebali biste više voljeti prekomjerno podešavanje nego spajanje kako bi vaša povijest bila uredna. Ako imate svoju osobnu vilicu spremišta, a koja se ne dijeli s drugim programerima, sigurno ćete izvršiti ponovnu bazu podataka čak i nakon što gurnete u svoju poslovnicu.
  • Vaš je kod spreman za pregled: stvorili ste zahtjev za povlačenjem. Drugi pregledavaju vaš rad i potencijalno ga preuzimaju u svoje račvanje za lokalni pregled. U ovom trenutku ne biste trebali preusmjeravati svoj rad. Trebali biste stvoriti 'preraditi' predaje i ažurirati svoju granu značajki. To pomaže u sljedivosti zahtjeva za povlačenjem i sprječava slučajno lomljenje povijesti.
  • Pregled je gotov i spreman za integriranje u ciljanu granu. Čestitamo! Izbrisat ćete svoju granu značajki. S obzirom na to da se drugi programeri od ovog trenutka neće spajati u tim promjenama, ovo je vaša prilika da sanirate svoju povijest. U ovom trenutku možete prepisati povijest i presaviti izvorne ureze i one dosadne 'pr preraditi' i 'spojiti' u mali skup fokusiranih predavanja. Stvaranje eksplicitnog spajanja za ove komitove nije obavezno, ali ima vrijednost. Bilježi kada je značajka diplomirala za svladavanje.

Zaključak

Nadam se da ovo objašnjenje je dao neke uvide na Git spajanja i Git rebase. O strategiji spajanja i ponovnog postavljanja uvijek je diskutabilno. No možda će vam ovaj članak pomoći da odagnate vaše sumnje i omogućite vam da usvojite pristup koji odgovara vašem timu.

Radujem se pisanju o Git tijekovima rada i konceptima Gita . Komentirajte teme o kojima želite da dalje pišem. Živjeli!

code = coffee + developer

škola kodiranja za programere