-
1. Početak
- 1.1 O kontroli verzije
- 1.2 Kratka istorija Gita
- 1.3 Osnove Gita
- 1.4 Komandna linija
- 1.5 Instaliranje Gita
- 1.6 Podešavanja za prvi put
- 1.7 Traženje pomoći
- 1.8 Rezime
-
2. Osnove Gita
- 2.1 Pravljenje Git repozitorijuma
- 2.2 Snimanje promena na repozitorijumu
- 2.3 Pregled istorije komitova
- 2.4 Opovrgavanje
- 2.5 Rad sa udaljenim repozitorijumima
- 2.6 Tagovanje
- 2.7 Alijasi
- 2.8 Rezime
-
3. Grananje u Gitu
- 3.1 Grananje ukratko
- 3.2 Osnove grananja i spajanja
- 3.3 Upravljanje granama
- 3.4 Tokovi rada sa grananjem
- 3.5 Udaljene grane
- 3.6 Rebaziranje
- 3.7 Rezime
-
4. Git on the Server
- 4.1 Protokoli
- 4.2 Postavljanje Gita na server
- 4.3 Generisanje javnog SSH ključa
- 4.4 Podešavanje servera
- 4.5 Git Daemon
- 4.6 Pametan HTTP
- 4.7 GitWeb
- 4.8 Opcije za hostovanje koje nude treća lica
- 4.9 Rezime
-
5. Distribuirani Git
- 5.1 Distribuirani tokovi rada
- 5.2 Kako doprineti projektu
- 5.3 Održavanje projekta
- 5.4 Rezime
-
6. GitHub
-
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugging with Git
- 7.11 Submodules
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Summary
-
8. Prilagođavanje Gita
- 8.1 Konfiguracija Gita
- 8.2 Git atributi
- 8.3 Git hukovi
- 8.4 Primer polise sprovedene od strane Gita
- 8.5 Rezime
-
9. Git i ostali sistemi
- 9.1 Git kao klijent
- 9.2 Migriranje na Git
- 9.3 Rezime
-
10. Git iznutra
- 10.1 Vodovod i porcelan
- 10.2 Git objekti
- 10.3 Git reference
- 10.4 Paketoteke
- 10.5 Refspek
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Summary
-
A1. Appendix A: Git in Other Environments
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Summary
-
A2. Appendix B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. Appendix C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
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.

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:
-
Održavalac projekta gurne promene na svoj javni repozitorijum.
-
Kontributor klonira taj repozitorijum i pravi promene.
-
Kontributor gura promene na ličnoj javnoj kopiji.
-
Kontributor šalje održavaocu mejl sa molbom da povuče promene.
-
Održavalac dodaje kontributorov repozitorijum kao rimout i spaja lokalno.
-
Održavalac gura spojene promene na glavni repozitorijum.

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.):
-
Obični developeri rade na svojim tematskih granama i rebaziraju svoj rad na vrh
master
-a. Master grana je diktatorova. -
Poručnici spajaju tematske grane developerâ u svoju
master
granu. -
Diktator spaja
master
grane poručnika u diktatorovumaster
granu. -
Diktator gura svoj
master
na referentni repozitorijum kako bi drugi developeri mogli da ga rebaziraju.

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.