-
1. Začetek
- 1.1 O nadzoru različic
- 1.2 Kratka zgodovina Gita
- 1.3 Kaj je Git?
- 1.4 Ukazna vrstica
- 1.5 Namestitev Gita
- 1.6 Prva nastavitev Gita
- 1.7 Pridobivanje pomoči
- 1.8 Povzetek
-
2. Osnove Git
- 2.1 Pridobivanje repozitorija Git
- 2.2 Snemanje sprememb v repozitorij
- 2.3 Pregled zgodovine potrditev
- 2.4 Razveljavljanje stvari
- 2.5 Delo z daljavami
- 2.6 Označevanje
- 2.7 Aliasi Git
- 2.8 Povzetek
-
3. Veje Git
- 3.1 Veje na kratko
- 3.2 Osnove vej in združevanja
- 3.3 Upravljanje vej
- 3.4 Poteki dela z vejami
- 3.5 Oddaljene veje
- 3.6 Ponovno baziranje
- 3.7 Povzetek
-
4. Git na strežniku
- 4.1 Protokoli
- 4.2 Pridobitev Gita na strežniku
- 4.3 Generiranje vaših javnih ključev SSH
- 4.4 Nastavitev strežnika
- 4.5 Prikriti proces Git
- 4.6 Pametni HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Možnosti gostovanja pri tretjih ponudnikih
- 4.10 Povzetek
-
5. Porazdeljeni Git
- 5.1 Porazdeljeni poteki dela
- 5.2 Prispevek k projektu
- 5.3 Vzdrževanje projekta
- 5.4 Povzetek
-
6. GitHub
-
7. Orodja Git
- 7.1 Izbira revizije
- 7.2 Interaktivno pripravljanje
- 7.3 Shranjevanje na varno (angl. stashing) in čiščenje
- 7.4 Podpisovanje vašega dela
- 7.5 Iskanje
- 7.6 Prepisovanje zgodovine
- 7.7 Demistifikacija ponastavitve
- 7.8 Napredno združevanje
- 7.9 Rerere
- 7.10 Razhroščevanje z Gitom
- 7.11 Podmoduli
- 7.12 Povezovanje v pakete
- 7.13 Zamenjava
- 7.14 Shramba poverilnic
- 7.15 Povzetek
-
8. Prilagoditev Gita
- 8.1 Konfiguracija Git
- 8.2 Atributi Git
- 8.3 Kljuke Git
- 8.4 Primer pravilnika, ki ga uveljavlja Git
- 8.5 Povzetek
-
9. Git in ostali sistemi
- 9.1 Git kot odjemalec
- 9.2 Migracija na Git
- 9.3 Povzetek
-
10. Notranjost Gita
- 10.1 Napeljava in keramika
- 10.2 Objekti Git
- 10.3 Reference Git
- 10.4 Packfiles (datoteke zmanjšanih podatkov)
- 10.5 Refspec
- 10.6 Protokoli prenosa
- 10.7 Vzdrževanje in obnovitev podatkov
- 10.8 Spremenljivke okolja
- 10.9 Povzetek
-
A1. Dodatek A: Git v drugih okoljih
- A1.1 Grafični vmesniki
- A1.2 Git v Visual Studio
- A1.3 Git v Visual Studio Code
- A1.4 Git v IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git v Sublime Text
- A1.6 Git v Bashu
- A1.7 Git v Zsh
- A1.8 Git v Powershellu
- A1.9 Povzetek
-
A2. Dodatek B: Vdelava Gita v vašo aplikacijo
- A2.1 Git v ukazni vrstici
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Dodatek C: Ukazi Git
- A3.1 Nastavitev in konfiguracija
- A3.2 Pridobivanje in ustvarjanje projektov
- A3.3 Osnove posnetkov
- A3.4 Veje in združevanje
- A3.5 Deljenje in posodabljanje projektov
- A3.6 Pregled in primerjava
- A3.7 Razhroščevanje
- A3.8 Popravljanje
- A3.9 E-pošta
- A3.10 Zunanji sistemi
- A3.11 Administracija
- A3.12 Orodja za sisteme napeljave
1.1 Začetek - O nadzoru različic
To poglavje bo namenjeno začetnim korakom z Gitom. Začeli bomo razlago ozadja o orodjih za nadzor različic, nato se premaknili na to, kako pognati Git na vašem sistemu in na koncu, kako ga nastaviti, da začnete delo. Po zaključku tega poglavja bi morali razumeti, čemu je Git na voljo, zakaj bi ga morali uporabljati in morali bi biti pripravljeni za delo z njim.
O nadzoru različic
Kaj je »nadzor različic« in zakaj bi morali za to skrbeti? Nadzor različic je sistem, ki s časom zapisuje spremembe v datoteko ali skupek datotek, da lahko kasneje prikličete določeno različico. Za primere v tej knjigi boste uporabljali izvorno kodo programske opreme kot datoteke, ki bodo nadzirane v različicah, vendar v resnici lahko to naredite s skoraj katerimkoli tipom datotek na računalniku.
Če ste grafični ali spletni oblikovalec in želite slediti vsaki različici slike ali postavitve (kar nadvse verjetno želite), je sistem nadzora različic (VCS) zelo modra odločitev za uporabo. Omogoča vam povrniti datoteke v prejšnje stanje, povrniti celoten projekt v prejšnje stanje, primerjati spremembe s časom, pogledati, kdo je nazadnje kaj spremenil, kar bi lahko povzročalo težavo, kdo in kdaj je uvedel težavo ter še več. Uporaba VCS tudi v splošnem pomeni, da če kaj zamočite ali izgubite datoteke, lahko enostavno stvari povrnete. Poleg tega dobite vse to za zelo majhno ceno.
Lokalni sistemi nadzora različic
Za veliko ljudi je metoda izbire nadzora različic kopiranje datotek v drug direktorij (mogoče časovno označen direktorij, če so pametni). Ta pristop je zelo pogost, ker je tako enostaven, vendar je tudi zelo dovzeten za napake. Enostavno je pozabiti, v katerem direktoriju ste in po nesreči pišete v napačno datoteko ali prepišete datoteke, ki jih niste želeli.
Za spoprijemanje s to težavo so programerji že davno nazaj razvili lokalne VCS-je, ki so imeli enostavno podatkovno bazo, ki je shranjevala vse spremembe na datotekah pod nadzorom različic.
![Diagram lokalnega nadzora različic](png/local.png)
Eno priljubljenejših orodij VCS je bil sistem, imenovan RCS, ki je še danes deljen na mnogih računalnikih. RCS deluje tako, da obdrži skupke popravkov (to so razlike med datotekami) v posebni obliki na disku; nato pa lahko ponovno ustvari, kako je bila katerakoli datoteka videti v kateremkoli času z dodajanjem vseh popravkov.
Centralizirani sistemi nadzora različic
Naslednja glavna težava, na katero ljudje naletijo, je, da morajo sodelovati z razvijalci na drugih sistemih. Za spoprijemanje s tem problemom so bili razviti centralizirani sistemi nadzora različic (CVCS-ji). Ti sistemi (kot so CVS, Subversion in Perforce) imajo en strežnik, ki vsebuje vse različice datotek in več odjemalcev, ki izvlečejo datoteke iz tega osrednjega mesta. Mnoga leta je bil to standard za nadzor različic.
![Diagram centraliziranega nadzora različic](png/centralized.png)
Ta namestitev ponuja mnoge prednosti, posebej preko lokalnih VCS-jev. Na primer, vsakdo ve do določene mere, kaj kdorkoli drug na določenem projektu dela. Skrbniki sistema imajo drobno zrnat nadzor nad tem, kdo lahko kaj naredi, in za administracijo CVCS-jev je to precej enostavnejše, kot pa se spoprijemati z lokalnimi podatkovnimi bazami na vsakem odjemalcu.
Vendar ta namestitev ima tudi nekatere resne slabosti. Najbolj očitna je odpoved ene same točke, ki jo centralizirani strežnik predstavlja. Če ta strežnik odpove za eno uro, potem med to uro nihče ne more sodelovati ali shraniti sprememb različic na karkoli, na čemer delajo. Če se trdi disk, na katerem je osrednja podatkovna baza, poškoduje in ustrezne varnostne kopije niso bile ohranjene, boste izgubili absolutno vse — celotno zgodovino projekta razen samega posnetka, ki ga imajo uporabniki na svojih lokalnih napravah. Lokalni sistemi VCS trpijo za enakim problemom — kadarkoli imate celotno zgodovino projekta na enem mestu, tvegate, da boste izgubili vse.
Porazdeljeni sistemi nadzora različic
To je mesto, kjer pristopijo porazdeljeni sistemi nadzora različic (DVCS-ji). V DVCS (kot je Git, Mercurial, ali Darcs) odjemalci ne izvlečejo samo zadnjega posnetka datotek: v celoti kopirajo repozitorij skupaj s celotno zgodovino. V primeru, da katerikoli strežnik odpove in ti sistemi sodelujejo preko tega strežnika, se lahko kopira repozitorij katerega koli odjemalca na strežnik ter se povrne. Vsak klon je resnično celotna varnostna kopija vseh podatkov.
![Diagram porazdeljenega nadzora različic](png/distributed.png)
Poleg tega se mnogo teh sistemov precej dobro spoprijema z mnogimi oddaljenimi repozitoriji, na katerih lahko delajo, tako da lahko sodelujete z različnimi skupinami ljudi na različne načine istočasno znotraj istega projekta. To vam omogoča postaviti več tipov poteka dela, ki na centraliziranih sistemih, kakršni so hierarhični modeli, niso možni.