-
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. Приложение A: Git в други среди
- A1.1 Графични интерфейси
- A1.2 Git във Visual Studio
- A1.3 Git във Visual Studio Code
- A1.4 Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git в Sublime Text
- A1.6 Git в Bash
- A1.7 Git в Zsh
- A1.8 Git в PowerShell
- A1.9 Обобщение
-
A2. Приложение B: Вграждане на Git в приложения
- A2.1 Git от команден ред
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Приложение C: Git команди
- A3.1 Настройки и конфигурация
- A3.2 Издърпване и създаване на проекти
- A3.3 Snapshotting
- A3.4 Клонове и сливане
- A3.5 Споделяне и обновяване на проекти
- A3.6 Инспекция и сравнение
- A3.7 Дебъгване
- A3.8 Patching
- A3.9 Email команди
- A3.10 Външни системи
- A3.11 Административни команди
- A3.12 Plumbing команди
4.2 Git на сървъра - Достъп до Git на сървъра
Достъп до Git на сървъра
Сега ще разгледаме настройката на Git услуга, ползваща тези протоколи на ваш собствен сървър.
Забележка
|
Тук ще демонстрираме командите и стъпките за базови опростени инсталации на Linux базиран сървър, но разбира се, възможно е това да стане на macOS и Windows машини. В действителност, изграждането на production сървър в рамките на вашата инфраструктура ще изисква различни стъпки по отношение на мерките за сигурност или според конкретните инструменти на операционната ви система, но да се надяваме, че тези стъпки ще ви дадат първоначална насока за това какво се изисква. |
Като първа стъпка, за да получите Git на сървъра, ще трябва да експортирате налично хранилище в ново, bare хранилище - това е хранилище, което не съдържа работна директория.
Това обикновено е съвсем лесно.
Използвайте командата за клониране с параметър --bare
.
По конвенция, директориите за 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 хранилището, без работната му директория и създава директория специално за него.
Изпращане на Bare хранилище към сървъра
След като вече имате копие на хранилището, всичко което трябва да сторите е да го копирате на сървъра и да настроите съответния протокол/протоколи за достъп.
Нека кажем, че имате сървър наречен 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
Ако някой от тях има и права за писане до директорията /srv/git/my_project.git
, то той ще има автоматично и push права до хранилището.
Git автоматично ще добави group write права до хранилището по коректен начин, ако изпълните git init
с параметъра --shared
.
Изпълнението на тази команда не унищожава никакви къмити, референции или други обекти
$ ssh user@git.example.com
$ cd /srv/git/my_project.git
$ git init --bare --shared
Виждате колко лесно е да вземете Git хранилище, да създадете bare версия и да го поставите в сървър, към който колегите ви имат SSH достъп. Сега сте готови да работите съвместно по проекта.
Важно е да посочим, че това буквално е всичко, от което имате нужда за да пуснете използваем Git сървър - просто добавете акаунти с SSH достъп за колегите ви и копирайте едно bare хранилище там, където те имат права за четене и писане. Сега сте готови, не трябва нищо повече.
В следващите секции ще видим как да направим по-модерни конфигурации. Ще направим обзор на това как да настроите нещата така, че да не се нуждаете от отделни акаунти за всеки потребител, как да добавим публичен достъп за четене до хранилища, настройване на уеб потребителски интерфейси и др. Обаче, просто помнете, че това са допълнения - всичко, което ви трябва за да работите съвместно по частен проект е SSH сървър и bare хранилище.
Малки конфигурации
Ако сте малък екип или просто тествате Git във вашата организация и имате само няколко разработчика, нещата могат да са простички за вас. Един от най-сложните аспекти в настройката на Git сървъра е управлението на потребителите. Ако искате някои хранилища да са само за четене за определени потребители, а други да са достъпни за писане, то настройките на достъпа и съответните права могат да са по-трудни за наместване.
SSH достъп
Ако имате сървър, към който всичките ви колеги имат SSH достъп, най-лесно е да разположите хранилищата си в него, защото както видяхме в предната секция - няма да имате почти никаква работа по настройките. Ако искате по-комплексен контрол на достъпа, можете да се справите с нормалните средства за достъп до файловата система, които операционната система предлага.
Ако искате да разположите хранилищата си на сървър, който няма акаунти за всички в екипа ви, за които допускате, че ще е нужен достъп с права за писане, тогава трябва да настроите SSH достъп за тях. Допускаме, че ако имате сървър с който да правите това, вече имате инсталиран SSH за достъп до него.
Има няколко начина да дадете достъп на всеки от екипа.
Първо, можете да създадете акаунти за всички колеги, което е лесно, но може да е досадно.
Може да не искате да изпълнявате adduser
/useradd
и да правите временни пароли за всеки колега.
Втори начин е да създадете единичен 'git' потребител на машината, да помолите всеки ваш колега, който трябва да има права за писане да ви изпрати свой SSH публичен ключ, и да добавите ключовете във файла ~/.ssh/authorized_keys
на потребителя 'git'.
Така всеки от колегите ви ще има достъп до машината през потребителското име 'git'.
Това не засяга по никакъв начин commit данните — SSH потребителят, с който се свързвате към машината не се отразява на записаните къмити.
Друг начин е да настроите вашия SSH сървър да автентикира потребителите през LDAP сървър или някакъв друг централизиран източник за автентикация, който може да имате. Докато всеки от потребителите може да получи шел-достъп на машината, всеки SSH оторизационен механизъм за който се сещате, би трябвало да работи.