-
1. Начало
- 1.1 За Version Control системите
- 1.2 Кратка история на Git
- 1.3 Какво е Git
- 1.4 Конзолата на Git
- 1.5 Инсталиране на Git
- 1.6 Първоначална настройка на Git
- 1.7 Помощна информация в Git
- 1.8 Обобщение
-
2. Основи на Git
-
3. Клонове в Git
-
4. Git на сървъра
- 4.1 Комуникационни протоколи
- 4.2 Достъп до Git на сървъра
- 4.3 Генериране на SSH публичен ключ
- 4.4 Настройка на сървъра
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Други опции за хостване
- 4.10 Обобщение
-
5. Git в разпределена среда
-
6. GitHub
-
7. Git инструменти
- 7.1 Избор на къмити
- 7.2 Интерактивно индексиране
- 7.3 Stashing и Cleaning
- 7.4 Подписване на вашата работа
- 7.5 Търсене
- 7.6 Манипулация на историята
- 7.7 Мистерията на командата Reset
- 7.8 Сливане за напреднали
- 7.9 Rerere
- 7.10 Дебъгване с Git
- 7.11 Подмодули
- 7.12 Пакети в Git (Bundling)
- 7.13 Заместване
- 7.14 Credential Storage система
- 7.15 Обобщение
-
8. Настройване на Git
- 8.1 Git конфигурации
- 8.2 Git атрибути
- 8.3 Git Hooks
- 8.4 Примерна Git-Enforced политика
- 8.5 Обобщение
-
9. Git и други системи
- 9.1 Git като клиент
- 9.2 Миграция към Git
- 9.3 Обобщение
-
10. Git на ниско ниво
- 10.1 Plumbing и Porcelain команди
- 10.2 Git обекти
- 10.3 Git референции
- 10.4 Packfiles
- 10.5 Refspec спецификации
- 10.6 Транспортни протоколи
- 10.7 Поддръжка и възстановяване на данни
- 10.8 Environment променливи
- 10.9 Обобщение
-
A1. Appendix A: Git в други среди
- A1.1 Графични интерфейси
- A1.2 Git във Visual Studio
- A1.3 Git във Visual Studio Code
- A1.4 Git в Eclipse
- A1.5 Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.6 Git в Sublime Text
- A1.7 Git в Bash
- A1.8 Git в Zsh
- A1.9 Git в PowerShell
4.8 Git на сървъра - GitLab
GitLab
GitWeb е доста семпъл вариант за визуализация. Ако търсите по-модерен, напълно функционален Git сървър, съществуват няколко проекта с отворен код, които са на ваше разположение. Понеже GitLab е един от най-популярните, ще разгледаме него за пример. Това е малко по-сложно от GitWeb и вероятно ще изисква повече поддръжка, но е и много по-пълноценна алтернатива.
Инсталация
GitLab е уеб приложение използващо база данни, така че инсталацията му изисква малко повече усилия сравнена с някои други Git сървъри. За щастие, този процес е много добре документиран и проектът активно се поддържа.
Има няколко различни метода за инсталиране на GitLab. Ако искате бързо да пуснете нещо, може да ползвате имидж за виртуална машина или пък one-click инсталатор от https://bitnami.com/stack/gitlab и след това да промените конфигурацията им според конкретните ви нужди. Един приятен компонент, който Bitnami са включили, е login екрана на виртуалната машина (достъпен с комбинацията alt+→); той ви казва IP адреса и фабричните потребителско име и парола на инсталирания GitLab.
За всичко друго, ползвайте упътването за GitLab Community Edition, достъпно на адрес https://gitlab.com/gitlab-org/gitlab-ce/tree/master. Там ще намерите съдействие за инсталирането на GitLab през Chef recipes, на виртуална машина в Digital Ocean, и RPM и DEB пакети (които, по времето на писането на тази книга, са в бета версия). Съществуват също и “неофициални” напътствия за пускане на GitLab на нестандартни операционни системи и бази данни, напълно ръчен инсталационен скрипт и много други теми.
Администрация
Административният интерфейс на GitLab е достъпен през браузър.
Отворете страницата на IP адреса на машината, на която е инсталиран GitLab и се логнете като администратор.
Фабричното потребителско име е admin@local.host, а паролата 5iveL!fe (ще бъдете помолени да я промените веднага след входа).
След това натиснете иконата “Admin area” в менюто в горния десен край.
Потребители
Потребителите в GitLab са акаунти, които съответстват на хора.
Самите акаунти не са сложни; в основни линии представляват колекция от персонални данни прикачени към логин информацията.
Всеки потребителски акаунт притежава namespace, за логическо групиране на проектите, които притежава.
Така, ако потребител с име jane има проект с име project, то този проект ще е с url http://server/jane/project.
Изтриването на потребител може да стане по два начина. “Блокирането” на потребител забранява логването му в GitLab инстанцията, но всички данни в съответния namespace ще бъдат запазени и всички къмити подписани с имейл адреса на този потребител ще сочат все още към съответния потребителски профил.
“Изтриването” от своя страна, тотално унищожава потребителя от базата данни и файловата система. Всички проекти и данните в съответния namespace се изтриват и всички групи, които потребителят притежава, също се изтриват. Очевидно тази втора опция е много по-деструктивна и се използва рядко.
Групи
GitLab групата представлява съвкупност от проекти плюс информация за това как потребителите имат достъп до тях.
Всяка група има namespace за проектите (по същия начин като потребителите), така че ако групата training съдържа проект materials, то неговият url ще бъде http://server/training/materials.
Всяка група е асоциирана с множество потребители, всеки от които разполага с ниво на достъп до групата и проектите в нея. То варира от “Guest” (с достъп до issues и chat) до “Owner” (пълен контрол над групата, членовете ѝ и нейните проекти). Типовете права са твърде много, за да ги изброяваме всичките, но GitLab има полезни линкове за помощ в административния интерфейс.
Проекти
Един GitLab проект приблизително съответства на единично Git хранилище. Всеки проект принадлежи на един namespace, потребителски или на група. Ако проектът принадлежи на потребител, то този потребител има пряк контрол върху това кой ще има достъп до него; ако е в група, то тогава user-level правата на групата ще се приложат съответно.
Всеки проект има също така ниво на видимост, което контролира кой има права за четене на страниците и хранилището му.
Ако един проект е Private, то собственикът му трябва изрично да даде права за достъп на него до потребителите, които пожелае да го виждат.
Internal проектите са видими за всеки логнат потребител, а Public проектите са видими за всички.
Това контролира както git fetch достъпа, така и достъпа до уеб UI интерфейса за този проект.
Hooks
GitLab подържа hooks като способ за сигнализация, на ниво проект и система. За всеки от тях, GitLab сървърът ще направи HTTP POST заявка с описателна JSON-фирматирана информация, когато възникнат съответните събития. Това е полезен начин да свържете вашите Git хранилища и GitLab инстанцията си към останалата част от автоматизацията на разработките като например CI сървъри, чат стаи или deployment инструменти.
Използване
Вероятно най-напред ще искате да създадете GitLab проект. Това се прави чрез иконата “+” на лентата с инструменти. Ще трябва да въведете име за проекта, към кой namespace ще принадлежи той и какво ниво на видимост ще има. Повечето от тези неща не са перманентни и могат да се редактират по-късно. Натиснете “Create Project” и сте готови.
След като проектът съществува, вероятно ще искате да го свържете с локално Git хранилище.
Всеки проект е достъпен през HTTPS или SSH и всеки от тези протоколи може да се използва като Git remote.
Адресите са видими в горната част на страницата на проекта.
В налично локално Git хранилище, тази команда ще създаде отдалечена референция с име gitlab към хостваната локация:
$ git remote add gitlab https://server/namespace/project.gitАко нямате локално копие на хранилището, може просто да изпълните:
$ git clone https://server/namespace/project.gitУеб интерфейсът осигурява достъп до множество удобни изгледи на самото хранилище. Домашната страница на всеки проект показва последната активност и линковете в горната част ще ви преведат до изгледи на файловете в проекта и историята на къмитите.
Съвместна работа
Най-простият начин за съвместна работа в GitLab е да дадете на друг потребител директно push права за достъп до Git хранилището ви. Можете да добавите потребител към проекта от секцията “Members” в настройките на проекта, където може да асоциирате и ниво на достъп за него (различните нива на достъп се разглеждат по-подробно в Групи). Давайки на потребителя ниво “Developer” или по-високо, вие му позволявате свободно да изпраща къмити и клонове директно в хранилището.
Друг метод за колаборация е чрез използването на merge requests.
Тази функция позволява на всеки потребител, който вижда даден проект, да сътрудничи в него по контролиран начин.
Потребителите с директен достъп могат просто да създадат клон, да изпратят в него къмити и да отворят merge request от техния клон обратно в master или който и да е друг клон.
Потребителите без push права за дадено хранилище могат да го клонират при себе си (“fork”), да правят къмити в това тяхно копие и да отворят merge request от него обратно към основния проект.
Този модел на работа позволява на собственика на проекта да има пълен контрол върху това какво и кога влиза в хранилището и едновременно с това да позволява сътрудничество от непознати потребители.
Merge requests и issues са основните обекти на дискусиите в GitLab. Всеки merge request позволява line-by-line дискусия на предложената промяна (което поддържа олекотен вид code review), както и обща дискусионна нишка. И двата обекта могат да се асоциират към потребители или да се организират в milestones.
Тази секция е фокусирана основно върху Git функциите на GitLab, но като един наистина зрял проект, той предлага много други възможности за съвместна работа на екипа ви като например множество wiki за проектите и инструменти за системна поддръжка. Едно от предимствата на GitLab е в това, че веднъж настроен и пуснат, рядко ще ви се налага да променяте конфигурационен файл или да влизате в сървъра през SSH; повечето административни задачи се осъществяват през уеб интерфейса.