Git
Chapters ▾ 2nd Edition

5.1 Distribuirani Git - Distribuirani tokovi rada

Sada kada imate podešen udaljen Git repozitorijum kao tačku na kojoj svi programeri dele svoj kôd, i pošto ste upoznati sa osnovnim Git komandama u lokalnom toku rada, vreme je da bacimo pogled na to kako iskoristiti neke od distribuiranih tokova rada u Gitu.

U ovom poglavlju, videćete kako da radite sa Gitom u distribuiranom okruženju kao kontributor i integrator. Tačnije, naučićete kako da uspešno doprinese kôd projektu i da to učinite tako da rasteretite sebe i održavaoca projekta što je više moguće, kao i kako da održavate projekat uspešno sa većim brojem programera koji doprinose sadržaju.

Distribuirani tokovi rada

Za razliku od centralizovanih sistema za kontrolu verzije (CVCS), distributivna priroda Gita vam omogućava da budete mnogo fleksibilniji po pitanju načina na koji programeri kolaboriraju u projektima. Kod centralizovanih sistema, svi programeri su čvorovi koji manje-više jednako rade na centralnom habu. Kod Gita, međutim, svaki programer je potencijalno i čvor i hab — odnosno, svaki programer može i da doprinese kodu drugim repozitorijumima i da održava javni repozitorijum po kome drugi mogu da baziraju svoj rad i kome mogu da doprinesu. Ovo otvara ogroman spektar mogućnosti za tok rada za vaše projekte i/ili za vaš tim, zato ćemo preći nekoliko čestih paradigmi koje koriste ovu fleksibilnost. Pogledaćemo prednosti i moguće mane svakog dizajna; možete da izaberete samo jedan od njih koji ćete korstiti, ili možete da pomešate osobine iz svakog od njih.

Centralizovan tok rada

U centralizovanim sistemima, generalno postoji jedinstven kolaboracioni model — centralizovani tok rada. Jedan centralni hab, ili repozitorijum, može da prihvati kod, a svi drugi sinhronišu svoj rad prema njemu. Programeri su čvorovi — potrošači tog haba — i sinhronišu se prema tom jednom mestu.

Centralizovani tok rada.
Figure 54. Centralizovani tok rada.

Ovo znači da ako dva developera kloniraju sa haba i obojica naprave promene, prvi developer koji gurne svoje promene nazad na hab može to da uradi bez problema. Drugi developer mora da se spoji u rad prvog pre nego što gurne svoje promene, kako ne bi pisao preko promena koje je napravio prvi. Ovaj koncept je na Gitu isti kao i na Subversion-u (ili bilo kom drugom CVCS-u), i ovaj model radi odlično u Gitu.

Ako ste se već navikli na centralizovani tok rada u svojoj kompaniji ili timu, možete lako da nastavite da koristite taj tok rada sa Gitom. Jednostavno podesite jedan repozitorijum, i dajte svim članovima tima dozvolu za guranje na njega; Git neće dozvoliti korisnicima da pišu preko tuđih promena. Recimo da Marko i Milica počinju da rade istovremeno. Marko završava svoje promene i gura ih na server. Onda Milica pokušava da gurne svoje promene, ali server ih odbija. Server joj kaže da pokušava da gurne promene koje se ne uklapaju u metodu motanja unapred i da neće moći da uradi to dok ne pribavi podatke i ne uradi spoj. Ovaj tok rada odgovara mnogim ljudima jer je to paradigma na koju su navikli.

Ovo nije ograničeno samo na male timove. Sa Gitovim modelom za grananje, moguće je da na stotine developera uspešno radi na jednom projektu koristeći istovremeno na desetine grana.

Tok rada sa rukovodiocem integracija

Pošto Git dopušta da imate više udaljenih repozitorijuma, moguće je dizajnirati tok rada u kome svaki developer ima pristup čitanja sopstvenom javnom repozitorijumu i čitanja tuđih. Ovakav scenario često uključuje i kanonički repozitorijum koji predstavlja "zvaničan" projekat. Kako biste doprineli takvom projektu, treba da napravite sopstveni javni klon projekta i na njega gurate izmene. Onda treba da pošaljete zahtev održavaocu glavnog projekta da povuče vaše izmene. Održavalac onda može da doda vaš repozitorijum kao rimout, da testira promene lokalno, spoji ih u sopstvenu granu, i onda gurne nazad na repozitorijum. Ovaj proces radi na sledeći način:

  1. Održavalac projekta gurne promene na svoj javni repozitorijum.

  2. Kontributor klonira taj repozitorijum i pravi promene.

  3. Kontributor gura promene na ličnoj javnoj kopiji.

  4. Kontributor šalje održavaocu mejl sa molbom da povuče promene.

  5. Održavalac dodaje kontributorov repozitorijum kao rimout i spaja lokalno.

  6. Održavalac gura spojene promene na glavni repozitorijum.

Tok rada sa rukovodiocem integracija.
Figure 55. Tok rada sa rukovodiocem integracija.

Ovo je veoma čest tok rada sa alatima koji su bazirani na habovima kao što je GitHub ili GitLab, gde je lako forkovati projekat i gurnuti promene u svoj fork koje će svi videti. Jedna od glavnih prednosti ovog pristupa je to što možete da nastavite sa svojim radom, a održavalac glavnog repozitorijuma može da povuče vaše promene u bilo kom trenutku. Kontributirori ne moraju da čekaju da projekat pripoji njihove promene — svako radi svojim tempom.

Tok rada sa diktatorima i poručnicima

Ovo je varijanta toka rada sa više repozitorijuma. Generalno ga koriste ogromni projekti sa stotinama kolaboratora; jedan poznat primer je Linuks kernel. Razni rukovodioci integracijama su zaduženi za određene delove repozitorijuma; oni su poručnici. Svi poručnici imaju jednog rukovodioca integracijama poznat kao blagonakloni diktator. Repozitorijum blagonaklonog diktatora služi kao referentni repozitorijum sa kog svi kolaboratori treba da povuku. Ovaj proces radi na sledeći način (pogledajte Tok rada sa blagonaklonim diktatorom.):

  1. Obični developeri rade na svojim tematskih granama i rebaziraju svoj rad na vrh master-a. Master grana je diktatorova.

  2. Poručnici spajaju tematske grane developerâ u svoju master granu.

  3. Diktator spaja master grane poručnika u diktatorovu master granu.

  4. Diktator gura svoj master na referentni repozitorijum kako bi drugi developeri mogli da ga rebaziraju.

Tok rada sa blagonaklonim diktatorom.
Figure 56. Tok rada sa blagonaklonim diktatorom.

Ovakav tok rada nije čest, ali može da bude koristan kod velikih projekata, ili u okruženjima u kojima je hijerarhija jako izražena. Dozvoljava da vođa projekta (diktator) delegira veliki deo posla i sakuplja velike podskupove koda sa više mesta pre nego što ih integriše.

Rezime tokova rada

To su bili neki često korišćeni tokovi rada koje je moguće sprovesti u delo koristeći distibuirane sisteme kao što je Git, ali jasno je da su moguće mnoge varijacije koje treba prilagoditi određenom toku rada u praksi. Sada kada (bi trebalo da) možete da odlučite koja kombinacija tokova rada će vam odgovarati, pokrićemo neke specifičnije primene oko toga kako da obavite neke glavne zadatke ovih tokova rada. U sledećem odeljku, naučićete nešto o nekoliko čestih obrazaca po kojima se doprinosi projektu.