-
1. Введение
- 1.1 О системе контроля версий
- 1.2 Краткая история Git
- 1.3 Что такое Git?
- 1.4 Командная строка
- 1.5 Установка Git
- 1.6 Первоначальная настройка Git
- 1.7 Как получить помощь?
- 1.8 Заключение
-
2. Основы Git
-
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 Git-хостинг
- 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 Хранилище учётных данных
- 7.15 Заключение
-
8. Настройка Git
- 8.1 Конфигурация Git
- 8.2 Атрибуты Git
- 8.3 Хуки в Git
- 8.4 Пример принудительной политики Git
- 8.5 Заключение
-
9. Git и другие системы контроля версий
- 9.1 Git как клиент
- 9.2 Переход на Git
- 9.3 Заключение
-
10. Git изнутри
- 10.1 Сантехника и Фарфор
- 10.2 Объекты Git
- 10.3 Ссылки в Git
- 10.4 Pack-файлы
- 10.5 Спецификации ссылок
- 10.6 Протоколы передачи данных
- 10.7 Обслуживание репозитория и восстановление данных
- 10.8 Переменные окружения
- 10.9 Заключение
-
A1. Приложение A: Git в других окружениях
- A1.1 Графические интерфейсы
- A1.2 Git в Visual Studio
- A1.3 Git в Visual Studio Code
- A1.4 Git в Eclipse
- A1.5 Git в IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.6 Git в Sublime Text
- A1.7 Git в Bash
- A1.8 Git в Zsh
- A1.9 Git в PowerShell
- A1.10 Заключение
-
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 Основные команды
- A3.4 Ветвление и слияния
- A3.5 Совместная работа и обновление проектов
- A3.6 Осмотр и сравнение
- A3.7 Отладка
- A3.8 Внесение исправлений
- A3.9 Работа с помощью электронной почты
- A3.10 Внешние системы
- A3.11 Администрирование
- A3.12 Низкоуровневые команды
4.4 Git на сервере - Настраиваем сервер
Настраиваем сервер
Давайте рассмотрим настройку доступа по SSH на стороне сервера.
В этом примере мы будем использовать метод authorized_keys
для аутентификации пользователей.
Мы подразумеваем, что вы используете стандартный дистрибутив Linux типа Ubuntu.
Примечание
|
Вместо ручного копирования и установки открытых ключей, многое из описанного ниже может быть автоматизировано за счёт использования команды |
Для начала создадим пользователя git
и каталог .ssh
для этого пользователя:
$ sudo adduser git
$ su git
$ cd
$ mkdir .ssh && chmod 700 .ssh
$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
Затем вам нужно добавить открытые SSH-ключи разработчиков в файл authorized_keys
пользователя git
.
Предположим, у вас уже есть несколько таких ключей и вы сохранили их во временные файлы.
Напомним, открытый ключ выглядит примерно так:
$ cat /tmp/id_rsa.john.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
dAv8JggJICUvax2T9va5 gsg-keypair
Вы просто добавляете их в файл .ssh/authorized_keys
в домашнем каталоге пользователя git
:
$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
Теперь вы можете создать пустой репозиторий для них, запустив git init
с параметром --bare
, что инициализирует репозиторий без рабочего каталога:
$ cd /srv/git
$ mkdir project.git
$ cd project.git
$ git init --bare
Initialized empty Git repository in /srv/git/project.git/
После этого Джон, Джози или Джессика могут отправить первую версию их проекта в этот репозиторий, добавив его как удалённый и отправив соответствующую ветку.
Заметьте, что кто-то должен заходить на сервер и создавать голый репозиторий каждый раз, когда вы хотите добавить проект.
Пусть gitserver
— имя хоста сервера, на котором вы создали пользователя git
и репозиторий.
Если он находится в вашей внутренней сети и вы создали DNS запись для gitserver
, указывающую на этот сервер, то можно использовать следующие команды как есть (считая что myproject
это существующий проект с файлами):
# На компьютере Джона
$ cd myproject
$ git init
$ git add .
$ git commit -m 'Initial commit'
$ git remote add origin git@gitserver:/srv/git/project.git
$ git push origin master
Теперь все остальные могут клонировать его и отправлять в него изменения:
$ git clone git@gitserver:/srv/git/project.git
$ cd project
$ vim README
$ git commit -am 'Fix for README file'
$ git push origin master
Этим способом вы можете быстро получить Git-сервер с доступом на чтение/запись для небольшой группы разработчиков.
Заметьте, что теперь все эти пользователи могут заходить на сервер как пользователь git
.
Чтобы это предотвратить, нужно изменить ему оболочку на что-то другое в файле /etc/passwd
.
Вы можете легко ограничить пользователя git
только действиями, связанными с Git, с помощью ограниченной оболочки git-shell
, поставляемой вместе с Git.
Если указать её в качестве командного интерпретатора для пользователя git
, то он не сможет получить доступ к обычной командной оболочке на вашем сервере.
Для её использования, укажите git-shell
вместо bash или csh для пользователя git
.
Для этого вы должны сначала добавить git-shell
в /etc/shells
если её там ещё нет:
$ cat /etc/shells # посмотрим, присутствует ли `git-shell`. Если нет...
$ which git-shell # проверим, что `git-shell` установлена.
$ sudo -e /etc/shells # и добавим путь к `git-shell` из предыдущей команды
Теперь можно изменить оболочку для пользователя используя chsh <username> -s <shell>
:
$ sudo chsh git -s $(which git-shell)
Теперь пользователь git
может использовать SSH соединение только для работы с репозиториями Git и не может зайти на машину.
Если вы попробуете войти в систему, то вход будет отклонён:
$ ssh git@gitserver
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
Connection to gitserver closed.
На текущий момент пользователи всё ещё могут использовать перенаправление порта SSH для доступа к другим Git серверам, к которым текущий может подключиться.
Если это нужно отключить, вы можете добавить следующие опции в файл authorized_keys
перед теми ключами, для которых нужно применить это ограничение:
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
В результате файл будет выглядеть следующим образом:
$ cat ~/.ssh/authorized_keys
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4LojG6rs6h
PB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4kYjh6541N
YsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9EzSdfd8AcC
IicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myivO7TCUSBd
LQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPqdAv8JggJ
ICUvax2T9va5 gsg-keypair
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDEwENNMomTboYI+LJieaAY16qiXiH3wuvENhBG...
Теперь сетевые команды Git будут работать, но пользователи не смогут заходить на сервер.
Вы также можете создать подкаталог в домашнем каталоге пользователя git
, чтобы немного изменить поведение git-shell
.
Например, вы можете ограничить команды Git, которые сервер будет принимать или сообщение, которое увидят пользователи если попробуют зайти по SSH.
Для получения дополнительной информации по настройке оболочки запустите команду git help shell
.