-
1. Вступ
- 1.1 Про систему контролю версій
- 1.2 Коротка історія Git
- 1.3 Основи Git
- 1.4 Git, зазвичай, тільки додає дані
- 1.5 Три стани
- 1.6 Командний рядок
- 1.7 Інсталяція Git
- 1.8 Початкове налаштування Git
- 1.9 Отримання допомоги
- 1.10 Підсумок
-
2. Основи Git
- 2.1 Створення Git-репозиторія
- 2.2 Запис змін до репозиторія
- 2.3 Перегляд історії комітів
- 2.4 Скасування речей
- 2.5 Взаємодія з віддаленими сховищами
- 2.6 Теґування
- 2.7 Псевдоніми Git
- 2.8 Підсумок
-
3. Галуження в git
- 3.1 Гілки у кількох словах
- 3.2 Основи галуження та зливання
- 3.3 Управління гілками
- 3.4 Процеси роботи з гілками
- 3.5 Віддалені гілки
- 3.6 Перебазовування
- 3.7 Підсумок
-
4. Git на сервері
- 4.1 Протоколи
- 4.2 Отримання Git на сервері
- 4.3 Генерація вашого публічного ключа SSH
- 4.4 Налаштування Серверу
- 4.5 Демон Git
- 4.6 Розумний HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Варіанти стороннього хостингу
- 4.10 Підсумок
-
5. Розподілений Git
-
6. GitHub
-
7. Інструменти Git
- 7.1 Вибір ревізій
- 7.2 Інтерактивне індексування
- 7.3 Ховання та чищення
- 7.4 Підписання праці
- 7.5 Пошук
- 7.6 Переписування історії
- 7.7 Усвідомлення скидання (reset)
- 7.8 Складне злиття
- 7.9 Rerere
- 7.10 Зневадження з Git
- 7.11 Підмодулі
- 7.12 Пакування
- 7.13 Заміна
- 7.14 Збереження посвідчення (credential)
- 7.15 Підсумок
-
8. Налаштування Git
-
9. Git and Other Systems
- 9.1 Git як клієнт
- 9.2 Міграція на Git
- 9.3 Підсумок
-
10. Git зсередини
- 10.1 Кухонні та парадні команди
- 10.2 Об’єкти Git
- 10.3 Посилання Git
- 10.4 Файли пакунки
- 10.5 Специфікація посилань (refspec)
- 10.6 Протоколи передачі
- 10.7 Супроводження та відновлення даних
- 10.8 Змінні середовища
- 10.9 Підсумок
-
A1. Додаток A: Git в інших середовищах
- A1.1 Графічні інтерфейси
- A1.2 Git у Visual Studio
- A1.3 Git в Eclipse
- A1.4 Git у Bash
- A1.5 Git у Zsh
- A1.6 Git у Powershell
- A1.7 Підсумок
-
A2. Додаток B: Вбудовування Git у ваші застосунки
- A2.1 Git з командного рядка
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
-
A3. Додаток C: Команди Git
- A3.1 Налаштування та конфігурація
- A3.2 Отримання та створення проектів
- A3.3 Базове збереження відбитків
- A3.4 Галуження та зливання
- A3.5 Поширення й оновлення проектів
- A3.6 Огляд та порівняння
- A3.7 Зневаджування
- A3.8 Латання (patching)
- A3.9 Електронна пошта
- A3.10 Зовнішні системи
- A3.11 Адміністрування
- A3.12 Кухонні команди
4.8 Git на сервері - GitLab
GitLab
Проте GitWeb дуже простий. Якщо ви шукаєте більш сучасний Git сервер з багатшим функціоналом, існує декілька рішень з відкритим кодом, які ви можете встановити замість GitWeb. Оскільки GitLab є одним з найпопулярніших, ми розглянемо його інсталяцію та використання як приклад. Це трохи складніше, ніж варіант GitWeb, та напевно вимагає більше роботи, проте пропонує набагато більший функціонал.
Інсталяція
GitLab є веб програмою, що використовує базу даних для зберігання даних, отже його інсталяція вимагає більше знань, ніж деякі інші сервери Git. На щастя, є дуже детальний опис цього процесу.
Є декілька методів, як ви можете досягнути інсталяції GitLab. Щоб швидко отримати щось працююче, ви можете завантажити відбиток віртуальної машини чи інсталятор в один клік з https://bitnami.com/stack/gitlab, та підправити конфігурацію до особливих потреб вашого середовища. Ще одна приємна деталь, що її додала Bitnami, це екран входу (до якого можна перейти, набравши alt+→;). Він повідомляє вам IP адресу та логін/пароль до GitLab.
Екран входу віртуальної машини Bitnami GitLab. image::images/bitnami.png[Екран входу віртуальної машини Bitnami GitLab.]
За іншою інформацією звертайтеся до GitLab Community Edition readme, що можна знайти за адресою https://gitlab.com/gitlab-org/gitlab-ce/tree/master. Там ви знайдете підтримку щодо інсталяції GitLab за допомогою рецептів Chef, віртуальної машини на Digital Ocean, та з RPM або DEB пакетів (які, на момент написання, у бета-версії). Є також ``неофіційне'' керівництво по запуску GitLab з нестандартними операційними системами та базами даних, скрипт інсталяції повністю вручну, та багато іншого.
Адміністрування
GitLab пропонує веб-інтерфейс для адміністрування.
Просто направте ваш оглядач на ім’я хоста або IP адресу, де ви встановили GitLab, та заходьте як користувач admin.
Після інсталяції ім’я користувача admin@local.host, а пароль 5iveL!fie (який вас попросять змінити щойно ви зайдете).
Після входу, натисніть іконку меню ``Admin area'' нагорі праворуч.
Користувачі
Користувачі в GitLab є обліковими записами, що відповідають людям.
Облікові записи не дуже складні. Переважно це збір персональної інформації, прив’язаний до даних логіну.
Кожен користувач має простір імен, що є логічним групуванням проектів, що належать цьому користувачу.
Якщо користувач hanna мала проект під назвою project, то url цього проекту буде: http://server/hanna/project.
Видалити користувача можна двома методами. ``Блокування'' користувача не дає їм заходити на ваш GitLab, проте усі дані з їх простіру імен буде збережено, та фіксації з поштовою адресою цього користувача будуть продовжувати вказувати на його профіль.
``Винищення'' користувача, з іншого боку, повністю видаляє їх з бази даних та файлової системи. Усі проекти та дані в їх просторі імен видаляються, та будь-які групи, що їм належать, також будуть видалені. Це вочевидь більш деструктивна та незмінна дія, тому її використовують зрідка.
Групи
Група в GitLoab --- це збірка проектів, разом з даними про доступ користувачів до цих проектів.
Кожна група має простір імен проекту (так само, як користувачі), отже якщо група training має проект materials, його url буде http://server/training/materials.
Кожна група пов’язана з декількома користувачами, кожен з яких має свій рівень доступу до проектів групи та до самої групи.
Вони різняться від Guest'' (гість, тільки завдання (issues) та чат) до Owner'' (власник, повний контроль над групою, її користувачами та проектами).
Типи прав доступу занадто чисельні щоб наводити їх тут, проте GitLab пропонує корисне посилання на екрані адміністрування.
Проекти
Проект GitLab приблизно відповідає одному сховищу Git. Кожен проект належить до одного простору імен, що може належати користувачу або групі. Якщо проект належить користувачу, власник проекту має прямий контроль над правами доступу до проекту. Якщо проект належить групі, права доступу групи рівня користувачів також будуть враховані.
Кожен проект також має рівень доступу до перегляду, який контролює в кого є права на читання сторінок та сховища проекту.
Якщо проект Private (приватний), то власник проекту має окремо надати права кожному користувачу.
Internal (внутрішній) проект може бачити будь-який користувач, що здійснив вхід, а Public (публічний) проект може переглядати будь-хто.
Завважте, що це контролює і доступ до команди git fetch, і доступ до сторінок веб-інтерфейсу цього проекту.
Хуки
GitLab також підтримує хуки, як на рівні проекту, так і на рівні системи. Для кожного з них, сервер GitLab виконає HTTP POST з детальним описом у форматі JSON, щоразу трапляється якась релевантна подія. Це чудовий спосіб з’єднати ваші сховища Git та вашу копію GitLab з рештою ваших інструментів розробки, наприклад сервери безперервної інтеграції, кімнати чатів або утиліти розгортання.
Базове користування
Щойно ви встановите GitLab, ви забажаєте створити новий проект.
Щоб це здійснити, вам треба клікнути на значок +'' з панелі інструментів.
У вас запитають назву проекту, до якого простору імен він має належати, та який в нього має бути рівень доступу до перегляду.
Більшість заданих тут значень легко змінити потім за допомогою інтерфейсу налаштувань.
Натисніть Create Project'' (створити проект) коли ви будете готові.
Після створення проекту, ви напевно захочете з’єднати його з локальним сховищем Git.
Кожен проект є доступним через HTTPS чи SSH, їх обох можна використати для додавання видаленого Git сховища.
Ви можете побачити URL’и нагорі домашньої сторінки проекту.
Щоб додати видалене сховище під назвою gitlab до вже існуючого локального сховища:
$ git remote add gitlab https://server/namespace/project.gitЯкщо у вас немає локальної копію сховища, ви можете просто виконати:
$ git clone https://server/namespace/project.gitВеб інтерфейс надає доступ до декількох корисних представлень сховища. Домашня сторінка кожного проекту показує нещодавню діяльність, та посилання нагорі проведуть вас до переглядів файлів проекту та журналу фіксацій.
Співпраця
Найпростіший метод працювати над проектом GitLab разом - це надати іншому користувачу безпосередній доступ на викладання до сховища Git.
Ви можете додати користувача до проекту, якщо перейдете до секції Members'' налаштувань цього проекту, та задасте новому користувачу рівень доступу (різні рівні доступу трошки розглянуті в Групи).
Якщо ви дасте користувачу рівень доступу Developer'' або вищій, то користувач зможе безкарно викладати фіксації та гілки безпосередньо до сховища.
Інший, менш зчеплений шлях співпраці - це використання запитів на злиття (merge requests).
Він дозволяє будь-якому користувачу, що бачить ваш проект, робити внесок до нього під вашим наглядом.
Користувачі з безпосереднім доступом можуть просто створити гілку, викласти до неї зміни, та відкрити запит на злиття з їхньої гілки назад до master чи будь-якої іншої гілки.
Користувачі, що не мають прав викладати зміни до сховища, можуть ``форкнути'' його (створити власну копію), викласти фіксації до тієї копії, та відкрити запит на злиття з їхнього форку назад до головного проекту.
Ця модель дозволяє власнику повністю контролювати, що потрапить до сховища та коли, і в той же час дозволяє приймати внески від неперевірених користувачів.
Запити на злиття та завдання (issues) є головними предметами довгих обговорень в GitLab.
Кожен запит на злиття дозволяє порядкове обговорення пропонованих змін (що підтримує легку версію перевірки коду), а також загальне обговорення всього запиту.
Обидва можуть бути призначені користувачам, чи організовані у віхи (milestone).
Ця секція переважно розглядала функціонал GitLab пов’язаний з Git, проте це зрілий проект, він пропонує багато іншого функціоналу для допомоги вашій команді, наприклад вікі проекту та утиліти по підтримці системи. Одна з переваг GitLab в тому, що після налаштування та запуску серверу, вам тільки зрідка доведеться змінювати файл конфігурації або заходити до серверу через SSH. Більшість адміністративних та загальних завдань доступні через веб інтерфейс.
