-
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 Водоводне команде
4.8 Гит на серверу - GitLab
GitLab
Ипак је GitWeb прилично једноставан. Ако вам треба модернији Гит сервер са пуним могућностима, постоји неколико решења отвореног кода које можете да инсталирате уместо њега. Пошто је GitLab један од популарнијих, покрићемо његову инсталацију и коришћење као пример. Ово је мало сложеније од GitWeb опције и захтеваће више напора око одржавања, али због тога пружа потпуне могућности.
Инсталација
GitLab је веб апликација која се ослања на базу података, тако да је њена инсталација мало компликованија од инсталације неких других Гит сервера. Срећом, процес је доста добро документован и подржан. GitLab топло препоручује да GitLab инсталирате на сопствени сервер помоћу званичног Omnibus GitLab пакета.
Остале опције за инсталацију су:
-
GitLab Helm карта, за употребу са Kubernetes.
-
Докеризовани GitLab пакети за употреби са програмом Docker.
-
Фајлови изворног кода.
-
Провајдери клауд услуга као што су AWS, Google Cloud Platform, Azure, OpenShift и Digital Ocean.
За више информација прочитајте GitLab Community Edition (CE) ’прочитајме’ фајл.
Администрација
GitLab интерфејсу за администрацију се приступа преко веба.
Једноставно усмерите свој интернет прегледач на име хоста или IP адресу на коју је GitLab инсталиран и пријавите се као администратор.
Подразумевано корисничко име је admin@local.host, а подразумевана лозинка је 5iveL!fe (коју морате да промените чим је укуцате).
Када се пријавите, кликните на иконицу „Admin area” у горњем десном углу.
Корисници
Свако ко користи ваш GitLab сервер мора да поседује кориснички налог.
Кориснички налози су заиста једноставни, садрже углавном личне информације везане за податке за пријаву.
Сваки кориснички налог има простор имена, односно логичко груписање пројеката који припадају том кориснику.
Ако корисник jane има пројекат под именом project, URL адреса тог пројекта би била http://server/jane/project.
Уклањање корисничког налога се може обавити на два начина: „Блокирањем” се корисник спречава да се пријави на GitLab инстанцу, али се задржавају сви подаци под простором имена тог корисника, а комитови потписани мејл адресом тог корисника и даље имају линк до његовог профила.
С друге стране, „уништавање” корисника га у потпуности брише из базе података и фајл система. Уклањају се сви пројекти и подаци у његовом простору имена, као и све групе које поседује. Ово је очигледно много трајнија и деструктивнија операција која ће вам ретко бити потребна.
Групе
GitLab група је скуп пројеката заједно са подацима о начину на којем корисници могу да приступе тим пројектима.
Свака група има свој простор имена (као што га имају и корисници), тако да ако група training има пројекат materials, његова URL ће бити http://server/training/materials.
Свака група је придружена одређеном броју корисника, при чему сваки од њих има ниво дозволе за групне пројекте као и за саму групу. Ове дозволе се крећу од „Гост” (само за приступ тикетима и чету) до „Власник” (потпуна контрола над групом, њеним члановима и пројектима). Постоји превише типова дозвола да би се сви овде навели, али GitLab има користан линк на екрану за администрацију.
Пројекти
GitLab пројекат грубо одговара једном Гит репозиторијуму. Сваки пројекат припада једном простору имена, било кориснику или групи. Ако пројекат припада кориснику, власник пројекта има непосредну контролу над тиме ко има приступ пројекту; ако пројекат припада групи, користиће се групне дозволе за кориснички ниво.
Сваки пројекат има и ниво видљивости који контролише ко има приступ читања страница и репозиторијума тог пројекта.
Ако је пројекат Private, власник пројекта мора експлицитно да дозволи приступ одређеним корисницима.
Internal пројекат је видљив свим пријављеним корисницима, а Public свима.
Обратите пажњу на то да ово контролише и git fetch приступ, као и приступ веб корисничком интерфејсу тог пројекта.
Куке
GitLab поседује и подршку за куке, како на нивоу пројекта, тако и на нивоу система. У оба случаја, кад год се догоди неки релевантан догађај, GitLab сервер ће обавити HTTP POST са неким описним JSON. Ово је одличан начин да повежете своје Гит репозиторијуме и GitLab инстанцу са остатком аутоматизације тока развоја, као што су CI сервери, чет собе, или алати за развој.
Основна употреба
Прва ствар коју ћете хтети да урадите са GitLab је да креирате нови пројекат. Ово се једноставно обавља кликом на иконицу „+” из траке са алатима. Поставиће вам се питање за име пројекта, ком простору имена треба да припада и који би требало да буде ниво видљивости. Већина онога што овде дефинишете није трајно и може се накнадно променити путем интерфејса за подешавања. Кликните на „Create project” и то је то.
Сада када пројекат постоји, вероватно ћете хтети да га повежете са локалним Гит репозиторијумом.
Сваки пројекат је доступан преко HTTPS или SSH и оба се могу користити за конфигурисање удаљеног Гит репозиторијума.
URL адресе су видљиве на врху насловне странице пројекта.
За већ постојећи локални репозиторијум, следећа команда ће креирати удаљени репозиторијум gitlab везан за хостовану локацију:
$ git remote add gitlab https://сервер/простор_имена/пројекат.gitАко немате локалну копију репозиторијума, можете једноставно да урадите следеће:
$ git clone https://сервер/простор_имена/пројекат.gitВеб кориснички интерфејс нуди неколико корисних погледа на сам репозиторијум. Почетна страница сваког пројекта показује скорашњу активност, а линкови при врху ће вас одвести до погледа на фајлове пројекта и лог комитова.
Заједнички рад
Најједноставнији начин заједничког рада на GitLab пројекту је давање сваком кориснику дозволу за гурање на Гит репозиторијум. Корисника можете додати у пројекат одласком у одељак „Members” у подешавањима тог пројекта и повезивањем новог корисника са нивоом приступа (о различитим нивоима приступа се дискутује Групе.) Ако кориснику дате ниво приступа „Developer” или виши, тај корисник ће моћи да гура комитове и гране директно у репозиторијум.
Још један раздвојенији начин сарадње је помоћу захтева за спајањем.
Ова могућност дозвољава да било који корисник који види пројекат може и да му доприноси на контролисани на начин.
Корисници са директним приступом могу једноставно да направе грану, гурну комитове на њу, и отворе захтев за спајањем из њихове гране на грану master, или на било коју другу грану.
Корисници који немају дозволу за гурање на репозиторијум могу да га „форкују” (креирају своју копију), гурну комитове на своју копију, отворе захтев за спајањем из своје рачве назад на главни пројекат.
Овај модел дозвољава власнику да има потпуну контролу над тиме шта иде у репозиторијум и када, а допушта да допринос пројекту дају и корисници који немају поверење.
Захтеви за спајањем и тикети су главне јединице за дугорочне GitLab дискусије. Сваки захтев за спајањем допушта да се о предложеној измени расправља линија по линију (што подржава једноставну врсту прегледа кода), као и општу дискусију о целокупној промени. Оба могу да се доделе корисницима, или да се организују у прекретнице.
Овај одељак се највише усредсредио на GitLab могућности које имају везе са програмом Гит, али будући да је зрео пројекат, GitLab нуди и многе друге могућности које ће вам помоћи у раду са тимом, као што су викији пројекта и алати за одржавање система. Једна од предности GitLab система је то што када се сервер једном подигне и покрене, ретко ћете имати потребу да мењате конфигурациони фајл или да приступате серверу преко SSH; већина административних и општих задатака може се обавити преко интерфејса из интернет прегледача.
