-
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 Водоводне команде
5.1 Дистрибуирани Гит - Дистрибуирани процеси рада
Сада када имате подешен удаљен Гит репозиторијум као централну тачку на којој сви програмери деле свој кôд и пошто сте упознати са основним командама програма Гит у локалном току рада, време је да представимо начин за искоришћавање неких од дистрибуираних токова рада које вам нуди програм Гит.
У овом поглављу ћете видети како да радите са програмом Гит у дистрибуираном окружењу као сарадник и као интегратор. Тачније, научићете како да успешно допринесете кôд пројекту и како да себи и одржаваоцу пројекта олакшате посао што је више могуће, као и како да успешно одржавате пројекат са већим бројем програмера који доприносе садржају.
Дистрибуирани процеси рада
За разлику од централизованих система за контролу верзије (CVCS), дистрибутивна природа програма Гит вам омогућава да будете много флексибилнији по питању начина на који програмери сарађују на пројектима. Код централизованих система, сваки програмер је чвор који ради мање више исто као и централни хаб. Међутим, у програму Гит сваки програмер је потенцијално и чвор и хаб — односно, сваки програмер може и да даје допринос коду у другим репозиторијумима и да одржава јавни репозиторијум према коме други могу да базирају свој рад и коме могу да дају допринос. Ово отвара огроман спектар могућности за процес рада вашег пројекта и/или вашег тима, тако да ћемо прећи неколико честих парадигми које користе предност ове прилагодљивости. Представићемо предности и могуће мане сваког дизајна; можете да изаберете само један од њих који ћете користити, или можете да помешате могућности сваког од њих.
Централизован процес рада
У централизованим системима, у општем случају постоји јединствен модел сарадње — централизовани процес рада. Један централни хаб, или репозиторијум, може да прихвати кôд, а сви синхронизују свој рад са њим. Већи број програмера су чворови — потрошачи тог хаба — и синхронизују се са том централизованим местом.
![Централизовани процес рада](png/centralized_workflow.png)
Ово значи да ако два програмера клонирају са хаба и обојица направе промене, први програмер који гурне своје промене назад на хаб може то да уради без проблема. Други програмер мора да споји рад првог у свој пре него што гурне узводно своје промене, како не би преписао промене које је направио први програмер. Овај концепт је важи у програму Гит исто као и у Subversion (или у било ком другом CVCS), а овај модел ради савршено добро у програму Гит.
Ако сте се већ навикли на централизовани процес рада у својој компанији или тиму, лако можете наставити да користите тај процес рада са програмом Гит. Једноставно подесите један репозиторијум, дајте свим члановима тима дозволу за гурање на њега; програм Гит неће дозволити да корисници пишу преко туђих промена.
Рецимо да Марко и Милица почињу да раде истовремено. Марко завршава своју промену и гура је на сервер. Онда Милица покушава да гурне своје промене, али сервер их одбија. Сервер јој каже да покушава да гурне промене које не могу да се премотају унапред и да то неће моћи да уради све док не преузме податке и не споји их са својим. Овај процес рада је привлачан многим људима јер је то парадигма која им је позната и која им одговара.
Ово није ограничено само на мале тимове. Са Гитовим моделом гранања је могуће да на стотине програмера успешно ради на једном пројекту користећи истовремено на десетине грана.
Процес рада са руководиоцем интеграције
Пошто вам програм Гит допушта да имате више удаљених репозиторијума, могуће је користити процес рада у коме сваки програмер има приступ уписа у сопствени јавни репозиторијуму и приступ читања свих осталих. Овакав сценарио често укључује и канонички репозиторијум који представља „званичан” пројекат. Ако желите да дате допринос таквом пројекту, треба да направите сопствени јавни клон пројекта и на њега гурате измене. Онда можете да пошаљете захтев одржаваоцу главног пројекта да повуче ваше измене. Одржавалац онда може да дода ваш репозиторијум као удаљени репозиторијум, локално тестира ваше промене, споји их у сопствену грану, па онда гурне назад на свој репозиторијум. Овај процес ради на следећи начин (погледајте Процес рада са руководиоцем интеграције):
-
Одржавалац пројекта гурне промене на свој јавни репозиторијум.
-
Особа која даје допринос клонира тај репозиторијум и прави промене.
-
Особа која даје допринос гура промене на своју личну јавну копију.
-
Особа која даје допринос шаље одржаваоцу имејл са молбом да повуче промене.
-
Одржавалац додаје репозиторијум особе која даје допринос као удаљени репозиторијум и спаја локално.
-
Одржавалац гура спојене промене на главни репозиторијум.
![Процес рада са руководиоцем интеграције](png/integration-manager.png)
да Ово је веома чест процес рада са алатима који су базирани на хабовима као што је GitHub или GitLab, када је лако рачвати пројекат и гурнути промене у своју рачву које ће сви видети. Једна од главних предности овог приступа је то што можете да наставите са својим радом, а одржавалац главног репозиторијума може да повуче ваше промене у било ком тренутку. Особе које дају допринос не морају чекати да пројекат прихвати њихове промене — свако може да ради својим темпом.
Процес рада са диктатором и поручницима
Ово је варијанта процеса рада са више репозиторијума. У општем случају га користе огромни пројекти са стотинама сарадника; један познати пример је Линукс кернел. Више руководиоца интеграције су задужени за одређене делове репозиторијума; они се називају поручници. Сви поручници имају једног руководиоца интеграцијом који се назива благонаклони диктатор. Благонаклони диктатор повлачи са њихових репозиторијума у референтни репозиторијум из ког сви сарадници морају да повлаче. Овај процес ради на следећи начин (погледајте Процес рада са благонаклоним диктатором):
-
Обични програмери раде на својим тематских гранама и ребазирају свој рад на врх
master
гране.master
грана је у референтном репозиторијуму у који гура диктатор. -
Поручници спајају тематске гране програмера у своју
master
грану. -
Диктатор спаја
мастер
гране поручника у диктаторовуmaster
грану. -
Напокон, диктатор гура своју
master
грану на референтни репозиторијум тако да остали програмери могу да га ребазирају.
![Процес рада са благонаклоним диктатором](png/benevolent-dictator.png)
Овакав процес рада није уобичајен, али може да буде користан код великих пројеката, или у окружењима у којима је хијерархија јако изражена. Дозвољава да вођа пројекта (диктатор) делегира велики део посла и сакупља велике подскупове кода са више места пре него што их интегрише.
Резиме процеса рада
То су били неки често коришћени процеси рада које је могуће користити у дистрибуираном систему као што је Гит, али јасно је да постоје многе варијације које одговарају вашем одређеном процесу рада у пракси. Сада када (надамо се) можете да одлучите која комбинација процеса рада вам одговара, приказаћемо неке специфичније примере начина на које можете да постигнете главне улоге које чине различите процесе рада. У следећем одељку ћете сазнати нешто о неколико честих образаца по којима се доприноси пројекту.