При вставке больших файлов в GitLib, используя http-доступ возникает ошибка 413 и как результат – файлы не передаются. В таком случае, лучше передавать информацию через ssh. Но, для этого, нужно несколько повозиться и настроить ssh-ключи. В данной статье описывается, как настроить ssh-доступ для GitLib.
После создания нового проекта стоит обратить внимание на 2 вещи:
- на подсказку вверху о невозможности записывать изменения при отсутствии SSH ключей
- на подсказки на странице о необходимых действиях – при создании нового проекта и при создании локального репозитория в существующем проекте.
Начнем с SSH ключей. Стоит различать 2 разновидности SSH пар ключей – которые использует Git и которые используют клиенты типа Source Tree, Tortoise Git. Проблема первой разновидности в том, что без лишних телодвижений допускается использование только одной пары ключей, в то время как каждый репозиторий требует уникальный ключ, вторых же можно наплодить неограниченное количество (на самом деле можно использовать более 1 пары ключей первого типа, но предлагаемые решения работают либо частично, либо не работают вообще).
Для начала, сделаем ключи для Git, для этого запустим Git Bash. Git подразумевает что в Windows среде ключи лежат по адресу ~ / .ssh / id_rsa, где ~ – путь к домашней директории пользователя (например c: \ Users \ USERNAME), в папке которого есть каталог .ssh, в котором лежит пара ключей – id_rsa.pub и id_rsa (соответственно публичная часть и приватная).
Пришло время для генерирования ключей, возвращаемся к Git Bash и в консоль вводим следующее:
ssh-keygen -t rsa -C “your_email@example.com””
Данная команда указывает Git Bash создать ключ с коментарием your_email@example.com (зачем он нужен, поймете чуть позже) в формате RSA. Внимательно вводим место сохранения ключа, в nix-like стиле с прямыми (а не обратными!!!) слешами:
c: / Users / USERNAME / .ssh / id_rsa
и дважды вводим пароль для дополнительной защиты ключа (passphrase):
Переходим в личном кабинете в профиль, на вкладку с SSH ключами:
и добавляем содержимое посредством Copy/Paste файла id_rsa.pub (title заполнять не нужно – подставляется автоматически из коментария к ключу, таким образом ключи удобно отличать визуально, не сравнивая fingerprints.)
Убеждаемся что файл принят системой:
HTTP доступ к репозиторию
Настала очередь собственно локального репозитория. Возвращаемся в Git Bash и поочередно вводим команды, которые услужливо подсказывает стартовая страница вашего проекта:
cd d: / projects / test – переходим в папку где будет лежать будущий проект
mkdir test-project – создаем новую папку для проекта
cd test-project – переходим в папку проекта
git init – инициализируем локальный репозиторий
touch README – создаем новый файл README
git add README – добавляем его к версионированию
git commit -m ‘first commit’ – делаем commit с коментарием о первом комите
git remote add origin http://gitlab.golovachcourses.com/Student/test-project.git – добавляем адрес удаленного репозитория в HTTP формате
git push -u origin master – отправляем изменения на сервер
Теперь если зайти в свой личный кабинет, то сначала увидим сообщение про создание новой ветки master в нашем тестовом проекте:
В файлах появился новый файл README:
но он пока пустой.
Галочка в зеленом кружочке сообщает что данная папка успешно подключена к VCS:
Итак, мы создали первый тестовый проект, подключили его к удаленному репозиторию по HTTP протоколу и сделали первый commit первого файла – README.
SSH доступ к репозиторию
Попробуем теперь изменить файл README и отправить изменения на сервер посредством SSH протокола через Tortoise Git. Для удаленного обновления вашего кода через Tortoise Git необходимо настроить и добавить к аккануте новыю пару SSH ключей, используя PuTTY Key Generator:
Полученную пару ключей необходимо сохранить (Save public key && Save private key) в том же месте где и предыдущие для дальнейшей настройки Git (пусть это будут соответственно test@gitlab.golovachcourses.com.pub и test@gitlab.golovachcourses.com.ppk).
Теперь добавим к первому сгенерированный ключ в вашем профиле:
В параметре Git -> Remote -> origin меняем ссылку на SSH вариант:
git@gitlab.golovachcourses.com:Student/test-project.git
и указываем новый PuTTY ключ.
Теперь наш локальный репозиторий в качестве протокола будет использовать SSH. Пробуем как это работает, для чего в уже существующий пустой файл README вносим любые правки и сохраняем.
Обратите внимание на то, что VCS реагирует на изменение локальной копии, которое не синхронизировано с удаленным:
Есть две возможности провести синхронизацию:
- отдельно по файлу (так как он у нас один, больше ничего в проекте нет)
- либо по всей папке (что делают чаще всего)
В первом случае ПКМ на файле -> Git commit -> “master”…
Во втором случае ПКМ на папке -> Git Sync (этот вариант и рассмотрим как более общий):
делаем commit
вводим описание commit-а
локальный commit прошел успешно, делаем push
вводим пароль для ключа (passphrase, что вводили при создании, понадобится только в первый раз)
вводим наш логин
пароль
и наслаждаемся сообщением о том что произведен новый commit в основную ветку
и видим что в нашем удаленном файле, доступном в репозитории на сервере уже есть внесенные нами изменения
И теперь папка с “проектом” имеет одинаковую ревизию что локально что удаленно:
Git GUI клиенты
Помимо рассмотренного простейшего Tortoise Git (который на самом деле является не совсем GUI клиентом а скорее расширением оболочки), существует несколько других, для различных платформ: Git GUI. Из представленных заслуженное внимание привлекает Source Tree – добротный free инструмент от компании Atlassian.
Источник: http://gitlab.golovachcourses.com/root/manual/wikis/new_local_repository
Leave a Reply