-
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.2 Гит на серверу - Постављање програма Гит на сервер
Постављање програма Гит на сервер
Сада ћемо показати како се подешава Гит сервис тако да извршава ове протоколе на вашем сопственом серверу.
Белешка
|
Овде ћемо демонстрирати команде и кораке неопходне ради основне, поједностављене инсталације на серверу базираном на Линуксу, мада је могуће покренути ове сервисе и на мекОС или Виндоуз серверима. Заправо, постављање продукционог сервера унутар ваше властите инфраструктуре ће несумњиво подразумевати и неке разлике по питању сигурносних мера или алата које пружа оперативни систем, али надамо се да ће вам ово дати општу слику о томе шта треба урадити. |
Да бисте иницијално поставили било који Гит сервер, постојећи репозиторијум морате прво да извезете у нови огољени репозиторијум — репозиторијум који не садржи радни директоријум.
У општем случају се то ради једноставно.
Да бисте клонирали свој репозиторијум и направили нови огољени репозиторијум, можете да извршите команду clone
уз опцију --bare
.
По конвенцији, огољени репозиторијуми се завршавају са .git
, на пример:
$ git clone --bare my_project my_project.git
Cloning into bare repository 'my_project.git'...
done.
Сада би требало да имате копију података из Гит директоријума у директоријуму my_project.git
.
Ово је отприлике еквивалентно са следећим:
$ cp -Rf my_project/.git my_project.git
Постоји неколико малих разлика у конфигурационом фајлу; али за ову сврху, у питању је довољно приближна алтернатива. Ова команда узима сâм Гит репозиторијум, без радном директоријума, и креира директоријум намењен посебно њему.
Постављање огољеног репозиторијума на сервер
Сада када имате огољену копију репозиторијума, све што треба да урадите јесте да је окачите на сервер и поставите протоколе.
Рецимо да сте поставили сервер git.example.com
коме имате SSH приступ и све своје Гит репозиторијуме желите да ускладиштите у директоријум /srv/git
.
Под претпоставком да /srv/git
постоји на том серверу, нови репозиторијум можете да подесите тако што ћете тамо прекопирати свој огољени репозиторијум:
$ scp -r my_project.git user@git.example.com:/srv/git
Сада и други корисници који имају SSH приступ истом серверу за читање директоријума /srv/git
могу да клонирају ваш репозиторијум извршавањем:
$ git clone user@git.example.com:/srv/git/my_project.git
Ако корисник изврши SSH приступ серверу и има приступ писања у директоријум /srv/git/my_project.git
,
аутоматски ће имати и привилегију да гурају измене.
Програм Гит ће аутоматски додати групне дозволе за упис у репозиторијум ако покренете команду git init
уз опцију --shared
.
$ ssh user@git.example.com
$ cd /srv/git/my_project.git
$ git init --bare --shared
Видите колико је једноставно узети Гит репозиторијум, креирати његову огољену верзију и поставити је на сервер коме ви и ваши сарадници имате SSH приступ. Сада сте спремни за сарадњу над истим пројектом.
Важно је да приметити да је ово буквално све што треба да урадите ако желите да покренете употребљив Гит сервер коме неколико људи може да приступи — само додајте налоге који поседују SSH приступ на сервер и поставите огољени репозиторијум негде где сви ти корисницима имају приступ за читање и упис. Спремни сте да кренете — ништа више вам није потребно.
У следећих неколико одељака, видећете како да начините нека софистициранија подешавања. Ова дискусија ће показати и начин којим не морате да креирате корисничке налоге за сваког корисника, затим додавање јавног приступа за читање репозиторијумима, подешавање веб корисничких интерфејса и још тога. Ипак, имајте на уму да вам је за сарадњу неколико људи на приватном пројекту потребно да имате само SSH сервер и огољени репозиторијум.
Мали системи
Ако сте мала група људи или једноставно испробавате програм Гит за своју организацију и имате само неколико програмера, ствари за вас могу бити врло једноставне. Један од најкомпликованијих аспеката подешавања Гит сервера је управљање корисницима. Ако желите да неки репозиторијуми неким корисницима буду доступни само за читање, а другима и за читање и за упис, подешавање приступа и дозвола може бити нешто компликованије.
SSH приступ
Ако имате сервер коме сви програмери већ имају SSH приступ, у општем случају је најједноставније да прво тамо поставите први репозиторијум, јер скоро ништа више није потребно да урадите (као што смо видели у претходном одељку). Ако желите дозволе сложенијег типа контроле приступа над репозиторијумима, можете да их обрадите користећи уобичајене дозволе фајл система које поседује оперативни систем вашег сервера.
Ако своје репозиторијуме желите да поставите на сервер који нема налоге за сваку особу из тима којој желите да доделите права уписа, онда морате да подесите SSH за сваког од њих. Претпостављамо да ако имате сервер на којем ово можете остварити, већ имате инсталиран SSH сервер и да је то начин којим приступате серверу.
Постоји неколико начина на које можете свима из тима дозволити приступ.
Први је да подесите налоге за свакога, што је просто, али може бити заморно.
Можда не желите да покрећете adduser
(или могућу алтернативу useradd
) и да морате постављати привремене шифре за сваког новог корисника.
Друга метода је да на машини креирате јединственог корисника ’git’, па да питате сваког корисника који има приступ за упис на сервер да вам пошаље свој јавни SSH кључ и да додате тај кључ у фајл ~/.ssh/authorized_keys
тог новог корисника ’git’.
Сада сви могу да приступе машини кроз ’git’ налог.
Ово ни на који начин не утиче на комитоване податке — SSH корисник који се повезује никако не утиче на комитове које бележите.
Други начин да ово урадите јесте да подесите ваш SSH сервер тако да аутентификацију ради помоћу LDAP сервера или неког другог централизованог извора аутентификације ког сте већ подесили. Све док сваки корисник има приступ машини преко командног окружења, било који механизам за аутентификацију преко SSH који вам пада на памет би требало да функционише.