-
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.2 Git на сервері - Отримання Git на сервері
Отримання Git на сервері
Тепер ми розглянемо налаштування сервісу Git з цими протоколами на вашому власному сервері.
Зауваження
|
Тут ми продемонструємо команди та кроки, що потрібні для базового, спрощеного встановлення на Linux сервері, хоча ці сервіси також можуть працювати під Mac або Windows серверами. Насправді налаштування виробничого серверу у вашій інфраструктурі безперечно буде накладати відмінності у міри безпеки чи в роботі з системними утилітами, проте сподіваємось, що ця секція дасть вам загальне уявлення про процес. |
Щоб налаштувати сервер Git, спочатку треба експортувати існуюче сховище до нового чистого сховища — сховища, що не містить робочої теки.
Це доволі просто зробити.
Щоб зробити клон вашого сховища та створити нове чисте сховище, треба виконати команду clone з опцією --bare
.
За умовною домовленістю, теки чистих сховищ закінчуються суфіксом .git
, наприклад:
$ git clone --bare my_project my_project.git
Cloning into bare repository 'my_project.git'...
done.
Тепер у вас є копія даних теки Git у теці my_project.git
.
Це майже рівнозначно виконанню
$ cp -Rf my_project/.git my_project.git
Є декілька незначних відмінностей у файлі конфігурації, проте для наших цілей, це майже одне й те саме. Ми беремо саме сховище Git, без робочої теки, та створюємо теку спеціально і тільки для нього.
Розміщення чистого сховища на сервер
Тепер, коли у вас є чиста копія вашого сховища, все, що вам потрібно зробити — це розмістити його на сервері та налаштувати протоколи.
Припустімо, ви налаштували сервер за назвою git.example.com
, до якого у вас є SSH доступ, та ви бажаєте зберігати усі ваші сховища Git під текою /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 автоматично додасть групові права на запис до сховища вірно, якщо ви виконаєте команду git init
з опцією --shared
.
$ ssh user@git.example.com
$ cd /srv/git/my_project.git
$ git init --bare --shared
Бачите як просто взяти сховище Git, створити його чисту версію, та розмістити її на сервері, до якого ви та ваші колеги мають SSH доступ. Тепер ви готові до співпраці над одним проектом.
Важливо зазначити, що це літерально все, що вам потрібно щоб отримати працюючий корисний Git сервер, до якого мають доступ декілька людей — просто додайте SSH акаунти на сервері, та закиньте кудись чисте сховище, до якого всі користувачі мають доступ на читання та запис. Ось і все — більше нічого не треба.
У декількох наступних секціях, ви побачите як перейти до більш витончених схем. Ми розглянемо як не створювати акаунти для кожного користувача, як додати відкритий доступ на читання сховища, налаштування веб інтерфейсу та інше. Втім, пам’ятайте, що для співпраці з декількома людьми над закритим проектом, усе що треба — це SSH сервер і чисте сховище.
Маленькі проекти
Якщо ви маленька контора, або ви просто випробовуєте Git у вашій організації, та маєте тільки кількох програмістів, усе дуже просто. Один з найскладніших аспектів налаштування серверу Git — керування користувачами. Якщо ви бажаєте, щоб якісь сховища були доступні на читання деяким користувачам, а на читання та запис іншим, налаштувати доступ та права може бути трохи складніше.
SSH доступ
Якщо у вас є сервер, до якого всі ваші програмісти вже мають SSH доступ, зазвичай найпростіше встановити ваше перше сховище там, адже вам майже нічого не доведеться робити (як ми побачимо у наступній секцій). Якщо вам потрібен складніший контроль над доступом та правами до вашого сховища, ви можете з ними впоратися за допомогою звичайних прав доступу до файлів операційної системи вашого серверу.
Якщо ви бажаєте розмістити ваші сховища на сервері, до якого не у всіх з вашої команди, у кого має бути доступ на запис, є акаунти, вам треба налаштувати SSH доступ для них. Ми далі припускаємо, що на вашому сервері SSH сервер вже є встановленим, та ви саме так заходите на сервер.
Є декілька способів надати доступ усій вашій команді.
Ви можете просто додати акаунти всім, що є найпростішим варіантом, проте може бути трудомістким варіантом.
Ви можете не захотіти виконувати adduser
та встановлювати тимчасові паролі для кожного користувача.
Другий метод — це створити єдиного користувача git, попросити кожного користувача, у котрого має бути доступ на запис відправити вам публічний ключ SSH, та додати всі ключі до файлу ~/.ssh/authorized_keys
вашого нового користувача git.
Після цього, усі будуть мати доступ до машини через користувача git.
Це ніяким чином не впливає на дані коміту — користувач SSH, з якого ви підключаєтесь, не впливає на коміти, що ви записуєте.
Інший спосіб — це зробити, щоб SSH сервер авторизувався з LDAP серверу чи іншого централізованого джерела авторизації, що у вас може бути вже встановленим. Доки кожен користувач має доступ до командного рядка на машині, будь-якої автонтефікації SSH буде достатньо.