-
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
1.1 Početak - O kontroli verzije
Ovo poglavlje će se baviti nekim osnovnim stvarima o Gitu. Počećemo uz kratka objašnjenja o tome kako rade alati za kontrolu verzije, a onda ćemo preći na to kako podesiti Git da radi na sistemu koji koristite, i na kraju ćemo sve to namestiti da biste mogli da krenete sa radom. Na kraju poglavlja trebalo bi da razumete zašto Git postoji i zašto treba da ga koristite i bićete spremni da sve to sprovedete u delo.
O kontroli verzije
Šta je "kontrola verzije", i zašto bi vas to zanimalo? Kontrola verzije je sistem koji pamti promene fajla ili skupa fajlova tokom vremena kako biste mogli da se vratite na određene verzije kasnije. Za primere u ovoj knjizi koristićete izvorni kôd softvera kao fajlove nad kojima se primenjuje kontrola verzije, ali u stvarnosti ovakav pristup bi radio sa skoro svakom vrstom fajlova na računaru.
Ako ste grafički ili veb dizajner i želite da sačuvate svaku verziju slike ili makete (što je dobra praksa), vrlo je mudra ideja koristiti sistem za kontrolu verzije (Version Control System, VCS). Dozvoljava vam da vratite fajlove na pređašnje stanje, da vratite čitav projekat na pređašnje stanje, da poredite izmene tokom vremena, da vidite ko je poslednji modifikivao nešto što bi moglo da bude uzrok problema koji je nastao, ko je objavio da postoji neki problem i kada, i još mnogo toga. U opštem slučaju, korišćenje VCS-a znači i to da ako nešto zabrljate ili izgubite fajlove, lako možete da ih povratite. Štaviše, dobijate sve ovo uz veoma malo muke.
Lokalni sistemi za kontrolu verzije
Metoda za kontrolu verzija koju većina ljudi bira jeste kopiranje fajlova u drugi folder (oni mudriji bi mogli da ga recimo obeleže datumom). Ovaj pristup je veoma čest jer je dosta jednostavan, ali je istovremeno jako podložan greškama. Lako je zaboraviti u kom ste folderu i slučajno upisati nešto u pogrešan fajl ili kopirati preko fajlova koje ste nameravali da sačuvate.
Da bi se izborili sa ovim problemom, programeri su odavno razvili lokalne VCS-ove koji su imali jednostavnu bazu podataka koja je čuvala sve promene određenih fajlova.

Jedan od popularnijih alata za VCS bio je sistem zvan RCS, koji je i danas distribuiran uz mnoge računare.
Čak i popularni operativni sistem Mac OS X sadrži komandu rcs
kada se instalira Developer Tools.
RCS radi tako što čuva skup zakrpi (patch set, odnosno razlike između fajlova) u posebnom formatu na disku; onda se može ponovo dobiti izgled fajla u bilo kom vremenskom trenutku prolaskom kroz sve zakrpe.
Centralizovani sistemi za kontrolu verzije
Sledeći veliki problem na koji ljudi nailaze je potreba za kolaboracijom sa programerima na drugim sistemima. Da bi se izborili sa ovim problemom, razvijeni su centralizovani sistemi za kontrolu verzije (CVCS). Ovi sistemi, kao što su CVS, Subversion i Perforce imaju jedan server koji sadrži sve verzionisane fajlove, i određeni broj klijenata koji preuzimaju fajlove sa tog centralnog mesta. Tokom mnogo godina, ovo je bio standardan način za realizaciju kontrole verzije.

Ovakva postavka nudi mnoge prednosti, pogotovo nad lokalnim VCS-ovima. Na primer, svi do neke granice znaju šta ostali rade na projektu. Administratori imaju detaljnu kontrolu nad time ko može da uradi šta; i mnogo je lakše administrovati CVCS-om nego uhvatiti se u koštac sa lokalnim bazama podataka svakog klijenta.
Međutim, ovakva postavka ima i neke ozbiljne nedostatke. Najočigledniji je jedinstvena tačka kvara koju predstavlja ovako centralizovani server. Ako server bude u kvaru na sat vremena, nijedna osoba ne može da radi na projektu, niti da čuva verzionisane promene onoga što trenutno radi. Ako se hard-disk na kome se nalazi centralizovana baza podataka ošteti, gubi se apsolutno sve — čitava istorija projekta osim onih trenutnih vezija koje ljudi imaju na lokalnim mašinama. Lokalni VCS sistemi imaju isti ovaj problem — kad god se čitava istorija projekta nalazi na jednom mestu, postoji rizik gubitka svega.
Distribuirani sistemi za kontrolu verzije
Ovde dolaze na red distribuirani sistemi za kontrolu verzije (DVCS). Kod DVCS-ova (kao što su Git, Mercurial, Bazaar ili Darcs), klijenti ne preuzimaju samo trenutan izgled fajlova, već potpuno preslikavaju ceo repozitorijum. Tako, ako neki od servera prestane sa radom, a ovi sistemi su se povezali pomoću njega, svaki od klijentovih repozitorijuma može da se iskopira nazad na server da bi se on obnovio. Svaki klon je bukvalno rezerva svih podataka.

Štaviše, mnogi od ovih sistema se prilično dobro nose sa više repozitorijuma na daljinu sa kojima mogu da rade, tako da možete kolaborirati sa različitim grupama ljudi na različite načine istovremeno u istom projektu. Ovo vam omogućava da podesite nekoliko tipova tokova rada koji nisu mogući u centralizovanom sistemu, kao što su hijerarhijski modeli.