Git сервер что это

Git для начинающих. Урок 6.
git push и git pull

Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

Во втором уроке мы создавали репозитории на github и научились клонировать их. После этого мы работали только с локальным репозиторием, на своей машине. Сегодня мы рассмотрим взаимодействие с удаленным репозиторием.

Что такое push (пуш)

Это отправка данных на сервер, в удаленный репозиторий, на github. Данные — это коммиты и ветки.

Зачем пушить на сервер

для работы в команде, чтобы делиться своим кодом с коллегами
чтобы иметь резервную копию на случай потери данных на своей машине

Когда пушить на сервер

Когда сделали новый коммит или несколько коммитов

Как узнать, что есть незапушенные коммиты

В командной строке набрать git status

 $ git status On branch master $ git status On branch master Your branch is ahead of 'origin/master' by 5 commits. (use "git push" to publish your local commits) (use "git push" to publish your local commits)

Ключевая фраза здесь «Your branch is ahead of ‘origin/master’ by 5 commits.». Это значит, что у нас есть 5 неотправленных на сервер коммитов. Если незапушенных коммитов нет, то картина будет такая

 $ git status On branch master Your branch is up-to-date with 'origin/master'.

«is up-to-date» означает, что у нас нет незапушенных коммитов

В PhpStorm понять, есть ли неотправленные коммиты, можно посмотрев в окно Version Control — Log, где находятся метка master и origin/master. Если master выше, то есть незапушенные коммиты.

master и origin/master

Это ветки: локальная и удаленная (на сервере, в github). По умолчанию мы находимся в ветке master. Подробно работу с ветками мы рассмотрим в следующем уроке, а пока достаточно запомнить, что master — это то, что на нашей машине, а origin/master — в удаленном репозитории, на github.

git push в терминале

 $ git push origin master

push — что сделать, отправить
origin — куда, на сервер
master — что, ветку master

Как пушить в PhpStorm

Правый клик — Git — Repository — Push. — Кнопка Push

Что такое pull (пулл)

Это скачивание данных с сервера. Похоже на клонирование репозитория, но с той разницей, что скачиваются не все коммиты, а только новые.

Зачем пулиться с сервера

Чтобы получать изменения от ваших коллег. Или от себя самого, если работаете на разных машинах

git pull в терминале

 $ git pull origin master

pull — что сделать, получить данные
origin — откуда, с сервера
master — а точнее, с ветки master

Как пулить в PhpStorm

Правый клик — Git — Repository — Pull. — Кнопка Pull

Когда что-то пошло не так.

Иногда при работе в команде git push и git pull могут вести себя не так, как пишут в учебниках. Рассмотрим примеры

git push rejected

Вы сделали новый коммит, пытаетесь запушить его, а git в ответ выдает такое

 $ git push origin master To git@github.com:Webdevkin/site-git.git ! [rejected] master -> master (fetch first) error: failed to push some refs to 'git@github.com:Webdevkin/site-git.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull . ') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Написано много, но суть в том, что коммит отклонен, пуш не прошел. Почему?

Git устроен так, что локально мы можем коммитить сколько угодно. Но прежде чем отправить свои коммиты на сервер, то есть запушить, нужно подтянуть новые коммиты с сервера. Те самые, которые успели сделать наши коллеги. То есть сделать git pull.

Когда мы делаем git push, git сначала проверяет, а нет ли на сервере новых коммитов. Если они есть, то git выдает то самое сообщение — git push rejected. Значит, нам нужно сначала сделать git pull, а затем снова запушить

 $ git pull origin master remote: Enumerating objects: 4, done. remote: Counting objects: 100% (4/4), done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), done. From github.com:Webdevkin/site-git * branch master -> FETCH_HEAD 239892a..383b385 master -> origin/master Merge made by the 'recursive' strategy. README.md | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 README.md

Здесь нас подстерегает неожиданность — в терминале выскакивает окно редактирования коммита. Пока просто сохраним, что предложено по умолчанию и закроем редактор. Вот теперь можно пушить свои коммиты

 $ git push origin master Counting objects: 19, done. Delta compression using up to 4 threads. Compressing objects: 100% (17/17), done. Writing objects: 100% (19/19), 1.98 KiB | 0 bytes/s, done. Total 19 (delta 4), reused 0 (delta 0) remote: Resolving deltas: 100% (4/4), completed with 1 local object. To git@github.com:Webdevkin/site-git.git 383b385..f32b91e master -> master

Все, наши коммиты на сервере. При этом появится странный коммит «Merge branch ‘master’ of github.com:Webdevkin/site-git». Это так называемый мердж-коммит, о нем чуть ниже.

Если же при попытке пуша новых коммитов на сервере нет, то git push пройдет сразу и отправит наши коммиты на сервер.

Как избавиться от мердж-коммита

Мердж-коммит появляется, когда вы сделали локальный коммит, а после этого подтянули новые коммиты с сервера. Мердж-коммит не несет смысловой информации, кроме самого факта мерджа. Без него история коммитов выглядит чище.

Чтобы избавиться от него, подтягивайте изменения командой git pull с флажком —rebase

 $ git pull --rebase origin master

При этом ваш локальный коммит окажется «поверх» нового коммита с сервера, а мердж-коммита не будет. И не забудьте после этого запушить свой коммит на сервер.

Мердж-коммит в PhpStorm

PhpStorm помогает избавиться от мердж-коммитов через меньшее количество действий. Если мы запушим локальные коммиты и получим rejected из-за того, что на сервере есть новые коммиты, то PhpStorm выдаст предупреждение, где предложит выбрать вариант: как подтянуть новые коммиты, с мерждем или ребейзом. Жмите кнопку «Rebase», мердж-коммита не будет и при этом локальный коммит сразу запушится на сервер.

Внимание
Объяснения в тексте не передают точно возникающие проблемы, это нужно видеть в динамике. Поэтому лучше смотрите видеоуроки и еще лучше пробуйте сами повторять их содержание.

Что могу посоветовать

Если мы работаем в одиночку, то удаленный репозиторий нужен только для сохранения резевной копии. Скорее всего, мы будем в него только пушить.

Но при работе в команде имеет смысл подумать над такими вещами:

пушить коммиты почаще, чтобы коллеги быстрее получали доступ к новым изменениям
пулиться почаще — обратная ситуация, почаще получать свежие изменения
всегда пультесь с флажком ребейза — git pull —rebase origin master
не удивляйтесь, что при пуллах и пушах могут возникать подобные ситуации, как мы рассматривали выше
не стесняйтесь спрашивать коллег, если увидели незнакомую ситуацию
больше практикуйтесь. Посадите домашний проект на git и работайте с ним

Не переживайте, если иногда будете чувствовать себя, как друзья ниже. Это нормально, новый инструмент не осваивается за 5 минут. Немного практики, и мы будем понимать, почему иногда git ведет себя не так, как хочется, и главное, будем понимать, как это исправить.

git push pull whaaat

В следующем уроке мы узнаем, что такое ветки и будем активно работать с ними. Там мы будем активно использовать git push и git pull, и это поможет закрепить уже пройденный материал.

Спасибо за внимание и до встречи!

Все уроки курса

Вводный урок
1. Установка и базовая настройка git
2. Создание и клонирование репозитория git
3. Делаем первые изменения, git status и git diff
4. Коммиты и история коммитов, git commit, git log и git show
5. Подробнее об истории коммитов. Путешествие по истории
6. Работа с сервером, git push и git pull
7. Ветки — главная фишка git, git branch и git checkout
8. Работа с ветками на сервере, git fetch
9. Слияния или мерджи веток, git merge
10. Конфликты и их разрешение
Платная часть курса. Презентация
* 11. Работа с gitignore и git exclude
* 12. Буфер обмена git, git stash
* 13. Копирование коммитов, git cherry-pick
* 14. Отмена и редактирование последнего коммита
* 15. Отмена произвольного коммита, git revert
16. Склеивание коммитов, git rebase —interactive и git reflog
* 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
* 18. Работа с git rebase. Отличия от merge
* 19. Что такое git push —force и как с ним работать
* 20. Ищем баги с помощью git, git bisect
* 21. Как и зачем работать с тегами git
* 22. Процессы: github flow и git flow
* 23. Псевдонимы в git
24. Мердж-реквесты
* 25. Форки

Git сервер в локальной сети

GIT сейчас является самой популярной системой контроля версий исходного кода.

Проектов накапливается много и они становятся разношерстными.

Работаем на разных машинах и в разных операционных системах, появляется потребность в централизованном хранилище. Оно позволяет не только хранить проекты, но и распространять.

Для этих целей существует отличный сервис как Github, но мы будем использовать собственный git сервер.

Настройка собственного решения позволит нам создавать репозитории без ограничений и в любых размерах и количествах.

Место куда ставить операционную систему

Это может быть отдельный компьютер в локальной сети, виртуальная машина или даже docker контейнер. У меня сервер будет крутиться на виртуальной машине VMware Workstation.

Установка операционной системы

В качестве операционной системы подойдет любой дистрибутив linux.

Я буду использовать debian 10. Скачать его можно с сервера яндекса, выбрав версию и тип процессора. В моем случае актуальная версия 10.7.0 , процессор amd64 . Далее минимальный образ /bt-cd/debian-10.7.0-amd64-netinst.iso.torrent .

При установке создайте локального пользователя git.

Итак: имеем установленную систему. Пришло время ее настроить.

Настройка git сервера

Подразумевается, что установлен чистый debian без лишнего софта.

Зайдем в систему под пользователем git.

В debian по умолчанию отсутствует команда sudo . Она нужна для того, чтобы иметь возможность повышать свои привилегии до суперпользователя, но сначала нужно им стать. Для этого установим необходимый пакет

su - # Обязательный - в конце Пароль: root@git:/home/git apt-get install sudo

Далее нужно разрешить нашему пользователю git выполнять команды от root, путем добавления пользователя в дополнительную группу sudo

usermod -aG sudo git

Чтобы проверить, что пользователь был добавлен в группу sudo нужно вновь войти в систему и выполнить команду

id #uid=1000(git) gid=1000(git) группы=1000(git),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev)

Все в порядке! Теперь нужно обновить систему до последней версии

sudo apt-get update -y sudo apt-get upgrade -y

Теперь ставим необходимые пакеты

sudo apt-get install openssh-server git vim

Наши репозитории будут храниться в домашнем каталоге пользователя git в /home/git

Теперь настроим доступ по ssh на сервер по ключу.

Для этого в каталоге /home/git создадим папку .ssh и файл authorized_keys с ключами авторизованных пользователей и назначим им нужные права

mkdir -p ~/.ssh && chmod 0700 ~/.ssh touch ~/.ssh/authorized_keys && chmod 0600 ~/.ssh/authorized_keys

В качестве примера создадим тестовый репозиторий

git init --bare ~/test.git

На сервере должен быть статический ip адрес. Например такой 192.168.88.230.

На этом настройка git сервера закончена. Переходим к клиенту.

Настройка клиента

Под клиентом подразумевается пользователь на любой операционной системе, где установлен git и есть терминал.

Скачать и установить git можно с официального сайта https://git-scm.com

Для подключения к нашему серверу git нужно сгенерировать пары ключей у себя на машине в linux. Это делается так:

ssh-keygen -t rsa -b 4096 -C "email@text.ru" # Закрытый и открытый ключ соответственно #id_rsa_git_local #id_rsa_git_local.pub

Если ключи уже были сгенерированы, то теперь публичный ключ нужно передать на сервер и занести в файл ~/.ssh/authorized_keys

Скопировать ключ на сервер и занести в файл ~/.ssh/authorized_keys можно командой

ssh-copy-id -i ~/.ssh/id_rsa_git_local.pub git@192.168.88.230

Если такой возможности нет, то вручную, просто вывести файл

cat ~/.ssh/id_rsa_git_local.pub

И скопировать его содержимое в файл ~/.ssh/authorized_keys на сервере.

Еще вариант с подключением к серверу по ssh

cat ~/.ssh/id_rsa_git_local.pub | ssh git@192.168.88.230 'cat >> ~/.ssh/authorized_keys'

При необходимости удалить ключ на сервере можно командой

sed -i '1d' ~/.ssh/authorized_keys

Где 1d номер строки удаления.

Работа с тестовым репозиторием

Работаем с нашим тестовым репозиторием test.git .

Предположим на машине конечного пользователя проект размещен здесь по такому пути /home/alex/test/ , хотя это не важно.

Переходим в эту директорию и добавляем адрес внешнего репозитория в наш локальный репозиторий

git remote add origin git@192.168.88.230:test.git

Если нужно заменить адрес репозитория воспользуемся командой

git remote set-url origin git@192.168.88.230:test.git

Пишем код, делаем коммиты, создаем ветки и отправляем в наш гит в локальной сети

git push -u origin master

Если нужно развернуть уже созданный проект, то клонируем его

git clone git@192.168.88.230:test.git

Создать новый репозиторий на сервере можно таким образом, действуя от лица пользователя git:

ssh git@192.168.88.230 'git init --bare ~/repo_test.git'

Если все настроено правильно, должно работать без проблем.

Итог

Таким образом поднять свой сервер не составит особых проблем. Конечно, есть куда стремится путем совершенствования сервера.

Из очевидных плюсов:

Мы не ограничены при работе с git, любые плюшки гита нам доступны из коробки
Настраиваем сервер под себя.
Легко добавить и убрать нового пользователя, для ведения проектов, указав его публичный ключ в файле ~/.ssh/authorized_keys .
При желании можно разрешить доступ к вашему репозиторию из вне.

4.2 Git на сервере — Установка Git на сервер

Рассмотрим теперь установку сервиса Git с поддержкой этих протоколов на сервер.

Примечание

Здесь мы приводим команды и шаги, необходимые для базовой, упрощённой установки на Linux-сервер, но эти сервисы можно запустить и на MacOS или Windows сервере. На самом деле, установка боевого сервера в вашей инфраструктуре неминуемо будет иметь отличия в настройках безопасности или инструментах операционной системы, но мы надеемся дать вам общее понимание происходящего.

Для того чтобы приступить к установке любого сервера Git, вы должны экспортировать существующий репозиторий в новый голый репозиторий — репозиторий без рабочего каталога. Делается это просто. Чтобы создать новый голый репозиторий — во время клонирования используйте параметр —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

Если у пользователя есть права записи в каталог /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 (или useradd ) и задавать временные пароли.

Второй способ — это создать на сервере пользователя git , попросить всех участников, кому требуется доступ на запись, прислать вам открытый ключ SSH и добавить эти ключи в файл ~/.ssh/authorized_keys в домашнем каталоге пользователя git . Теперь все будут иметь доступ к этой машине используя пользователя git . Это никак не повлияет на данные в коммите — пользователь, под которым вы соединяетесь с сервером по SSH, не воздействует на созданные вами коммиты.

Другой способ сделать это — настроить SSH сервер на использование аутентификации через LDAP-сервер или любой другой имеющийся у вас централизованный сервер аутентификации. Вы можете использовать любой механизм аутентификации на сервере и считать что он будет работать для Git, если пользователь может получить доступ к консоли по SSH.

4.4 Git на сервере — Настраиваем сервер

Давайте рассмотрим настройку доступа по SSH на стороне сервера. В этом примере мы будем использовать метод authorized_keys для аутентификации пользователей. Мы подразумеваем, что вы используете стандартный дистрибутив Linux типа Ubuntu.

Примечание

Вместо ручного копирования и установки открытых ключей, многое из описанного ниже может быть автоматизировано за счёт использования команды ssh-copy-id .

Для начала создадим пользователя 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 -s :

$ 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 .