-
1. Почетак
- 1.1 О контроли верзије
- 1.2 Кратка историја програма Гит
- 1.3 Шта је Гит?
- 1.4 Командна линија
- 1.5 Инсталирање програма Гит
- 1.6 Подешавања за први пут
- 1.7 Тражење помоћи
- 1.8 Резиме
-
2. Основе програма Гит
- 2.1 Прављење Гит репозиторијума
- 2.2 Снимање промена над репозиторијумом
- 2.3 Преглед историје комитова
- 2.4 Опозив
- 2.5 Рад са удаљеним репозиторијумима
- 2.6 Означавање
- 2.7 Гит алијаси
- 2.8 Резиме
-
3. Гранање у програму Гит
- 3.1 Укратко о гранању
- 3.2 Основе гранања и спајања
- 3.3 Управљање гранама
- 3.4 Процеси рада са гранањем
- 3.5 Удаљене гране
- 3.6 Ребазирање
- 3.7 Резиме
-
4. Гит на серверу
- 4.1 Протоколи
- 4.2 Постављање програма Гит на сервер
- 4.3 Генерисање јавног SSH кључа
- 4.4 Подешавање сервера
- 4.5 Гит демон
- 4.6 Паметан HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Опције за хостовање које нуде трећа лица
- 4.10 Резиме
-
5. Дистрибуирани Гит
-
6. GitHub
-
7. Гит алати
- 7.1 Избор ревизија
- 7.2 Интерактивно стејџовање
- 7.3 Скривање и чишћење
- 7.4 Потписивање вашег рада
- 7.5 Претрага
- 7.6 Поновно исписивање историје
- 7.7 Демистификовани ресет
- 7.8 Напредно спајање
- 7.9 Rerere
- 7.10 Отклањање грешака са програмом Git
- 7.11 Подмодули
- 7.12 Паковање
- 7.13 Замена
- 7.14 Складиште акредитива
- 7.15 Резиме
-
8. Прилагођавање програма Гит
- 8.1 Конфигурисање програма Гит
- 8.2 Гит атрибути
- 8.3 Гит куке
- 8.4 Пример полисе коју спроводи програм Гит
- 8.5 Резиме
-
9. Гит и остали системи
- 9.1 Гит као клијент
- 9.2 Мигрирање на Гит
- 9.3 Резиме
-
10. Гит изнутра
- 10.1 Водовод и порцелан
- 10.2 Гит објекти
- 10.3 Гит референце
- 10.4 Pack фајлови
- 10.5 Рефспек
- 10.6 Протоколи за пренос
- 10.7 Одржавање и опоравак податак
- 10.8 Променљиве окружења
- 10.9 Резиме
-
A1. Додатак А: Програм Гит у другим окружењима
- A1.1 Графички интерфејси
- A1.2 Гит у Visual Studio
- A1.3 Гит у Visual Studio Code
- A1.4 Гит у IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Гит у Sublime Text
- A1.6 Гит унутар Bash
- A1.7 Гит у Zsh
- A1.8 Гит у Powershell
- A1.9 Резиме
-
A2. Додатак Б: Уграђивање програма Гит у ваше апликације
- A2.1 Гит из командне линије
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Додатак В: Гит команде
- A3.1 Подешавање и конфигурација
- A3.2 Набављање и креирање пројеката
- A3.3 Основно снимање
- A3.4 Гранање и спајање
- A3.5 Дељење и ажурирање пројеката
- A3.6 Инспекција и поређење
- A3.7 Отклањање грешака
- A3.8 Крпљење
- A3.9 Имејл
- A3.10 Спољни системи
- A3.11 Администрација
- A3.12 Водоводне команде
1.1 Почетак - О контроли верзије
Ово поглавље ће се бавити неким основним стварима о програму Гит. Почећемо уз кратка објашњења о томе како раде алати за контролу верзије, а онда ћемо прећи на то како подесити програм Гит да ради на систему који користите и на крају ћемо све то уклопити тако да можете почети са радом. На крају поглавља требало би да разумете зашто постоји програм Гит, зашто би требало да га користите и бићете спремни да све то спроведете у дело.
О контроли верзије
Шта је то „контрола верзије”, и зашто би вас то занимало? Контрола верзије је систем који памти промене фајла или скупа фајлова настале током времена и који вам омогућава да се касније вратите на одређене верзије. Као примере у овој књизи користићете изворни кôд софтвера као фајлове над којима се примењује контрола верзије, али у стварности овакав приступ би радио са скоро сваком врстом фајлова на рачунару.
Ако сте графички или веб дизајнер и желите да сачувате сваку верзију слике или макете (што је добра пракса), врло је мудра идеја користити систем за контролу верзије (Version Control System, VCS). Дозвољава вам да вратите фајлове на пређашње стање, да вратите читав пројекат на пређашње стање, да поредите измене током времена, да видите ко је последњи изменио нешто што би могло да буде узрок проблема који је настао, ко је објавио да постоји неки проблем и када, и још много тога. У општем случају, употреба VCS система подразумева и то да ако нешто забрљате или изгубите фајлове, лако можете да их повратите. Штавише, све ово добијате уз веома мало муке.
Локални системи за контролу верзије
Метода за контролу верзија коју већина људи бира јесте копирање фајлова у други директоријум (они мудрији би могли да га рецимо обележе датумом). Овај приступ је веома чест јер је доста једноставан, али је истовремено јако подложан грешкама. Лако је заборавити у ком директоријуму се налазите, па да случајно упишете нешто у погрешан фајл или копирате преко фајлова које сте намеравали да сачувате.
Да би се изборили са овим проблемом, програмери су одавно развили локалне VCS системе који су имали једноставну базу података у којој су се чувале све промене одређених фајлова.
![Дијаграм локалне контроле верзије](png/local.png)
Један од популарнијих алата за VCS био је систем под именом RCS, који се и данас испоручује уз многе рачунаре. RCS ради тако што у посебном формату на диску чува скуп закрпи (patch set, односно разлике између фајлова); онда се проласком кроз све закрпе може поново добити изглед фајла у било ком временском тренутку.
Централизовани системи за контролу верзије
Следећи велики проблем на који људи наилазе је потреба за сарадњом са програмерима на другим системима. Да би се изборили са овим проблемом, развијени су централизовани системи за контролу верзије (CVCS). Ови системи, као што су CVS, Subversion и Perforce имају један сервер који садржи све верзионисане фајлове, и одређени број клијената који преузимају фајлове са тог централног места. Током много година, ово је био стандардни начин за реализацију контроле верзије.
![Дијаграм централизоване контроле верзије](png/centralized.png)
Оваква поставка нуди многе предности, поготово над локалним VCS системима. На пример, сви до неке границе знају шта остали раде на пројекту. Администратори имају детаљну контролу над тиме ко шта може да уради и много је лакше да се администрира CVCS систем него борити се са локалним базама података сваког клијента.
Међутим, оваква поставка има и неке озбиљне недостатке. Најочигледнији је јединствена тачка квара коју представља овако централизовани сервер. Ако сервер буде у квару на сат времена, ниједна особа не може да ради на пројекту, нити да чува верзионисане промене онога што тренутно ради. Ако се хард диск на коме се налази централизована база података оштети, губи се апсолутно све — читава историја пројекта осим оних тренутних верзија које људи имају на локалним машинама. Локални VCS системи имају исти овај проблем — кад год се читава историја пројекта налази на једном месту, постоји ризик да се изгуби све.
Дистрибуирани системи за контролу верзије
Овде долазе на ред дистрибуирани системи за контролу верзије (DVCS). Код DVCS система (као што су Git, Mercurial, Bazaar или Darcs), клијенти не преузимају само тренутан изглед фајлова, већ потпуно пресликавају цео репозиторијум. Тако, ако неки од сервера престане са радом, а ови системи су се повезали помоћу њега, сваки од клијентових репозиторијума може да се ископира назад на сервер да би се он обновио. Сваки клон је буквално потпуна резервна копија свих података.
![Дијаграм дистрибуиране контроле верзије](png/distributed.png)
Штавише, многи од ових система се прилично добро носе са више репозиторијума на даљину са којима могу да раде, тако да можете сарађивати са различитим групама људи на различите начине истовремено у истом пројекту. Ово вам омогућава да подесите неколико типова токова рада који нису могући у централизованом систему, као што су хијерархијски модели.