Как клонировать репозиторий с gitlab ssh
Git инструкция для начинающих. Работаем с GitHub
Это запись о том как быстро начать работу с Git’ом. Не какой воды.
Установка Git
Первоначальная настройка git
Настройка SSH-авторизации
Далее жмем несколько раз “Enter” и получаем вот такое сообщение в консоли.
Далее копируем открытый ssh-ключ в буфер обмена. Команда для копирования вводится в зависимости от Вашей OS.
Для Mac
Для Linux (Ubuntu)
Для Windows (Git Bash)
Как ввести SSH ключ на стороне Git’a
Входим в свой аккаунт на Git’e, далее наводим курсор мышки на свою аватарку и жмем “Settings”:
Теперь жмем на вкладку “SSH and GPG keys”:
Далее нажимаем кнопку “New SSH Key”. Указываем имя и вставляем ключ в поле Key. Нажимаем Add Key.
Работа с репозиторием
Теперь на сайте github.com создадим новый репозиторий, если это новый проект.
Теперь перейдём в папку с проектом на локальной машине и дадим команду:
Клонирование репозитория
Покажу на примере Windows.
Когда вы создаете репозиторий на GitHub, он существует как удаленный репозиторий. Вы можете клонировать свой репозиторий, чтобы создать локальную копию на вашем компьютере и синхронизировать между этими двумя местоположениями.
В этой процедуре предполагается, что вы уже создали хранилище на GitHub или имеете существующее хранилище, принадлежащее кому-то, кому вы хотели бы внести свой вклад.
Клонирование репозитория с помощью командной строки
На GitHub перейдите на главную страницу репозитория.
Примечание. Если хранилище пустое, вы можете вручную скопировать URL-адрес страницы хранилища из браузера и перейти к шагу 4.
Откройте Git Bash. TerminalTerminal
Измените текущий рабочий каталог на место, где вы хотите сделать клонированный каталог.
Введите, git clone а затем вставьте URL-адрес, скопированный на шаге 2.
Нажмите Enter. Ваш местный клон будет создан.
Как настроить подключение к удаленному Git репозиторию
Удаленный репозиторий находится на сервере с git. мне нужно просто склонировать содержимое. никаких пушей обратно. там есть идентификация. сгенерил паблик кей и отослал спец-ту на той стороне. как мне добавить ранее сгенеренный-свой ключ через консоль и подключиться к серверу? какие команды. Windows 7 на моей машине.
3 ответа 3
Установка
Если ещё не установлен, то Git можно взять здесь. Вместе с ним будет unix-like консоль Git Bash.
Клонирование через SSH
Пример команды для клонирования через SSH.
В общем случае команда для клонирования по SSH выглядит так:
Не перепутайте с HTTPS, который потребует авторизации через логин-пароль:
Создание ssh-ключа.
На Windows можно как через cmd, так и Git Bash, на *nix — просто в консоли. Но в cmd я не разбираюсь, поэтому привожу инструкцию только для Git Bash & *nix:
Можно выбрать passphrase, который повышает надёжность, но его нужно будет вводить каждый раз при использовании. Если забудете — ключ бесполезен для дальнейшего использования.
После выполнения команды публичный ключ появляется соответственно в
Именно публичный ключ нужно передавать специалисту на той стороне. (Наверняка вы так и сделали, но всё-таки стоит об этом сказать)
Если всё сделали правильно, то при попытке соединения по ssh ключ будет использоваться автоматически.
Если ключ уже есть
В ней полностью показаны клиентские программы для работы с push-ом и pull-ом. У меня лично Windows недолюбливал родной Git клиент, но всегда прекрасно работает с Tortoise (есть в статье).
В ней есть полное руководство по подключению. Не уверен правильная ли это аналогия, но вы можете поставить себе программу Composer и ей подобные, после чего можно через консоль Windows полностью клонировать себе репозиторий с Git-а.
Если же касается более специфичного подключения именно к Git, то эта страница будет полезной: http://webhamster.ru/site/page/index/articles/comp/171
Добавил, как попросили, кратко содержимое статьи:
Идем на официальную страницу Git http://git-scm.com, кликаем на Download for Windows. В открывшемся окне кликаем на Full installer for official Git. Запускаем полученный exe-шник.
Я рекомендую выбрать «Run Git from the Windows Command Prompt». Все остальные опции можно оставлять по-умолчанию. После установки Git нужно перегрузиться или завершить сеанс пользователя и снова войти, чтобы применились изменения в системной переменной PATH.
Далее нужно проверить, доступен ли Git для работы. В любом каталоге даем команду:
Если получаем информацию о версии, то Git установлен и работает. Если получаем информацию что программа git не найдена, разбираемся что сделали не так.
Настройка SSH-ключей в Windows
В операционной системе Windows генератор SSH-ключей включен в комплект поставки Git. Для генерации ключей необходимо запустить на выполнение файл C:\Program Files\Git\Git bash.vbs. Его можно запустить как обычный exe-шник. Откроется программа «Консоль git». В ней надо дать команду:
Будьте внимательны, в этой консоли подглючивает копи-паст, проще ввести команду вручную. В качестве email указываем свой почтовый ящик. На запрос «Enter file in which to save the key» просто нажимаем Enter. При запросе пароля «Enter passphrase» и «Enter same passphrase again» просто нажимаем Enter. В процессе генерации ключей в консоли будет выдаваться примерно следующая информация:
После выполнения этой программы, в каталоге C:\Documents and Settings\username.ssh будут лежать файлы id_rsa и id_rsa.pub, они нам пригодятся в дальнейшем.
Установка SSH-ключа в GitHub
Нас колько я помню, эта часть ответа несколько изменилась в современном дизайне GitHub-а, но интуитивно можо найти.
Сразу после регистрации необходимо прописать в системе GutHub свой публичный ключ шифрования (открытый SSH-ключ). Для добавления ключа, надо в правом верхнем углу нажать «Account Settings».
В поле Title можно написать название компьютера, на котором сгенерирован публичный ключ. Можно писать по-русски.
После добавления ключа, компьютер может соединяться с GitHub через программу git, и никаких ошибок не должно возникать.
Работа с репозитарием на GitHub через программу Git
Начиная с этого момента, пляски вокруг web-интерфейса GitHub можно считать законченными. Далее можно работать только используя программу git.
Вначале нужно сделать небольшую настройку программы git: указать локальной системе git имя пользователя и email. Это делается следующими командами, которые можно выполнить, находясь в любом каталоге:
После этих настроек, можно заливать свои файлы в репозитарий. Переходим в каталог со своим проектом, и даем команды:
После этих команд на сервере GitHub образуется копии файлов того каталога, в котором были выполнены данные команды. Далее можно уже делать коммиты, заливки на сервер GitHub изменений, считывания изменений с сервера. Но это уже совсем другая история.
Cloning a repository
In this article
When you create a repository on your GitHub Enterprise Server instance, it exists as a remote repository. You can clone your repository to create a local copy on your computer and sync between the two locations.
About cloning a repository
You can clone a repository from GitHub.com to your local computer to make it easier to fix merge conflicts, add or remove files, and push larger commits. When you clone a repository, you copy the repository from GitHub.com to your local machine.
Cloning a repository pulls down a full copy of all the repository data that GitHub.com has at that point in time, including all versions of every file and folder for the project. You can push your changes to the remote repository on GitHub.com, or pull other people’s changes from GitHub.com. For more information, see «Using Git».
You can clone your existing repository or clone another person’s existing repository to contribute to a project.
Cloning a repository
On GitHub.com, navigate to the main page of the repository.
Above the list of files, click
To clone the repository using HTTPS, under «Clone with HTTPS», click
. To clone the repository using an SSH key, including a certificate issued by your organization’s SSH certificate authority, click Use SSH, then click
. To clone a repository using GitHub CLI, click Use GitHub CLI, then click
. 
Change the current working directory to the location where you want the cloned directory.
Press Enter to create your local clone.
To learn more about GitHub CLI, see «About GitHub CLI.»
You can also use the GitHub URL to clone a repository.
Cloning an empty repository
An empty repository contains no files. It’s often made if you don’t initialize the repository with a README when creating it.
On GitHub.com, navigate to the main page of the repository.
To clone your repository using the command line using HTTPS, under «Quick setup», click
. To clone the repository using an SSH key, including a certificate issued by your organization’s SSH certificate authority, click SSH, then click
Alternatively, to clone your repository in Desktop, click
Change the current working directory to the location where you want the cloned directory.
Press Enter to create your local clone.
Troubleshooting cloning errors
When cloning a repository it’s possible that you might encounter some errors.
If you’re unable to clone a repository, check that:
Help us make these docs great!
All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.
К этому моменту вы уже должны уметь делать большую часть повседневных задач, для которых вы будете использовать Git. Однако, для совместной работы в Git, вам необходим удалённый репозиторий. Несмотря на то, что технически вы можете отправлять и забирать изменения непосредственно из личных репозиториев, делать это не рекомендуется. Вы легко можете испортить то, над чем работают другие, если не будете аккуратны. К тому же, вам бы наверняка хотелось, чтобы остальные имели доступ к репозиторию даже если ваш компьютер выключен, поэтому наличие более надёжного репозитория обычно весьма полезно. Предпочтительный метод взаимодействия с кем-либо — это создание промежуточного репозитория, к которому вы оба будете иметь доступ, и отправка и получение изменений через него.
Запустить Git-сервер достаточно просто. Для начала следует выбрать протокол, который вы будете использовать для связи с сервером. Доступные протоколы с их достоинствами и недостатками описываются в первой части этой главы. Следующие части освещают базовые конфигурации с использованием этих протоколов, а также настройку вашего сервера для работы с ними. Далее мы рассмотрим несколько вариантов готового хостинга, которые можно использовать, если вы не против разместить ваш код на чужом сервере и не хотите мучиться с настройками и поддержкой вашего собственного сервера.
Если вас не интересует настройка собственного сервера, вы можете перейти сразу к последней части этой главы для настройки аккаунта на Git-хостинге, а затем перейти к следующей главе, где мы обсудим различные аспекты работы с распределенной системой контроля версий.
Удалённый репозиторий — это обычно голый (чистый, bare) репозиторий — репозиторий Git, не имеющий рабочего каталога. Поскольку этот репозиторий используется только для обмена, то нет причин создавать рабочую копию файлов на диске — достаточно хранить только данные Git.
Протоколы
Git умеет работать с четырьмя сетевыми протоколами для передачи данных: локальный, HTTP, Secure Shell (SSH) и Git. В этой части мы обсудим каждый из них и в каких случаях стоит или не стоит его использовать.
Локальный протокол
Базовым протоколом является Локальный протокол, для которого удалённый репозиторий — это другой каталог на диске. Наиболее часто он используется, если все члены команды имеют доступ к общей файловой системе, например к NFS, или, что менее вероятно, когда все работают на одном компьютере. Последний вариант не идеален, поскольку все копии вашего репозитория находятся на одном компьютере, что резко увеличивает вероятность потерять всё.
Если у вас смонтирована общая файловая система, вы можете клонировать, отправлять и получать изменения из локального репозитория. Чтобы клонировать такой репозиторий или добавить его в качестве удалённого в существующий проект, используйте путь к репозиторию в качестве URL. Например, для клонирования локального репозитория вы можете выполнить что-то вроде этого:
Чтобы добавить локальный репозиторий в существующий проект, вы можете воспользоваться командой:
Теперь вы можете отправлять и получать изменения из этого репозитория так, как вы это делали по сети.
Достоинства
Также это хорошая возможность быстро получить наработки из чьего-то рабочего репозитория. Если вы и ваш коллега работаете над одним и тем же проектом, и он хочет, чтобы вы что-то проверили, то запуск команды вроде git pull /home/john/project зачастую проще, чем отправлять и забирать с удалённого сервера.
Недостатки
Недостаток этого метода в том, что общий доступ обычно сложнее настроить и получить из разных мест, чем простой сетевой доступ. Если вы хотите отправлять со своего ноутбука находясь дома, вы должны смонтировать удалённый диск, что может оказаться сложнее и медленнее, чем доступ по сети.
Также важно упомянуть, что не всегда использование общей точки монтирования является быстрейшим вариантом. Локальный репозиторий быстр, только если вы имеете быстрый доступ к данным. Репозиторий на NFS часто медленнее, чем репозиторий через SSH на том же сервере, позволяющий Git использовать на полную локальные диски на каждой системе.
Наконец, этот протокол не защищает репозиторий от случайного повреждения. Все пользователи имеют доступ к «удалённому» каталогу и ничего не мешает изменению или удалению внутренних файлов Git и, как следствие, повреждению репозитория.
Протоколы HTTP
Git может работать через HTTP в двух различных режимах. До версии Git 1.6.6 был только один режим, очень простой и предназначенный только для чтения. В версии 1.6.6 появился новый, более умный режим, позволяющий Git более интеллектуально определять необходимость передачи данных, наподобие того, как это происходит при использовании SSH. В последние годы новый протокол стал очень популярен, так как он проще для пользователя и более эффективен. Новая версия часто называется Умным (Smart) HTTP, а старая Тупым (Dumb) HTTP. Сначала мы рассмотрим Умный протокол.
Умный HTTP
«Умный» протокол HTTP работает схожим с SSH или Git-протоколами образом, но поверх стандартных HTTP/S портов и может использовать различные механизмы аутентификации HTTP, это часто проще для пользователя, чем что-то вроде SSH, так как можно использовать аутентификацию по логину/паролю вместо установки SSH-ключей.
На самом деле для сервисов вроде GitHub, адрес URL, который вы используете для просмотра репозитория в браузере (например, https://github.com/schacon/simplegit), можно использовать для клонирования или, если у вас есть доступ, для отправки изменений.
Тупой HTTP
Чаще всего вы будете использовать Умный HTTP для чтения/записи, либо Тупой только для чтения. Случай совместного их использования встречаются редко.
Достоинства
Мы сосредоточимся на преимуществах Умной версии протокола HTTP.
Простота использования одного адреса URL для всех типов доступа и аутентификации только при необходимости упрощает работу для конечного пользователя. Возможность аутентификации посредством логина и пароля также даёт преимущество перед SSH, так как пользователям перед использованием не нужно создавать SSH-ключи и загружать публичный ключ на сервер. Для неопытных пользователей или пользователей систем, где SSH мало распространён, это большой плюс. Это также очень быстрый и эффективный протокол, сравнимый с SSH.
Вы также можете предоставлять доступ к своим репозиториям только для чтения по HTTPS, шифруя содержимое передачи; или вы можете зайти так далеко, что клиенты будут использовать персональные подписанные SSL-сертификаты.
Другой плюс в том, что HTTP/S очень распространённые протоколы и корпоративные брандмауэры часто настроены для разрешения их работы.
Недостатки
На некоторых серверах Git поверх HTTP/S может быть немного сложнее в настройке по сравнению с SSH. Кроме этого, преимущества других протоколов доступа к Git перед Умным HTTP незначительны.
Если вы используете HTTP для аутентифицированной отправки изменений, ввод учётных данных зачастую сложнее, чем при использовании SSH-ключей. Но есть несколько инструментов для кеширования учётных данных, включая Keychain access на OSX и Credential Manager на Windows, которые вы можете использовать для упрощения процесса. В разделе Хранилище учётных данных главы 7 рассказывается как настроить безопасное кэширование пароля в вашей системе.
Протокол SSH
Часто используемый транспортный протокол для самостоятельного хостинга Git — это SSH. Причина этого в том, что доступ по SSH уже есть на многих серверах, а если его нет, то его очень легко настроить. К тому же, SSH — протокол с аутентификацией, и его благодаря распространённости обычно легко настроить и использовать.
Чтобы клонировать Git-репозиторий по SSH, вы можете указать префикс ssh:// в URL, например:
Или можно использовать для протокола SSH краткий синтаксис наподобие scp:
Также вы можете не указывать имя пользователя, Git будет использовать то, под которым вы вошли в систему.
Достоинства
SSH имеет множество достоинств. Во-первых, SSH достаточно легко настроить — демоны SSH распространены, многие системные администраторы имеют опыт работы с ними и во многих дистрибутивах они предустановлены или есть утилиты для управления ими. Далее, доступ по SSH безопасен — данные передаются зашифрованными по авторизованным каналам. Наконец, так же как и протоколы HTTP/S, Git и локальный протокол, SSH эффективен благодаря максимальному сжатию данных перед передачей.
Недостатки
Недостаток SSH в том, что, используя его, вы не можете обеспечить анонимный доступ к репозиторию. Клиенты должны иметь доступ к машине по SSH, даже для работы в режиме только на чтение, что делает SSH неподходящим для проектов с открытым исходным кодом. Если вы используете Git только внутри корпоративной сети, то, возможно, SSH — единственный протокол, с которым вам придётся иметь дело. Если же вам нужен анонимный доступ на чтение для своих проектов, придётся настроить SSH для себя, чтобы выкладывать изменения, и что-нибудь другое для других, для скачивания.
Git-протокол
Достоинства
Git-протокол ― часто самый быстрый из доступных протоколов. Если у вас проект с публичным доступом и большой трафик, или у вас очень большой проект, для которого не требуется аутентификация пользователей для чтения, вам стоит настроить демон Git для вашего проекта. Он использует тот же механизм передачи данных, что и протокол SSH, но без дополнительных затрат на шифрование и аутентификацию.
Недостатки
Недостатком Git-протокола является отсутствие аутентификации. Поэтому обычно не следует использовать этот протокол как единственный способ доступа к вашему проекту. Обычно он используется в паре с SSH или HTTPS для нескольких разработчиков, имеющих доступ на запись, тогда как все остальные используют git:// с доступом только на чтение. Кроме того, это, вероятно, самый сложный для настройки протокол. Вы должны запустить отдельный демон, для чего необходимо дополнительно настраивать xinetd или systemd или им подобные, что не всегда легко сделать. Также необходимо, чтобы сетевой экран позволял доступ на порт 9418, который не относится к стандартным портам, всегда разрешённым в корпоративных брандмауэрах. За сетевыми экранами крупных корпораций этот неизвестный порт часто заблокирован.
How can I clone a private GitLab repository?
I am getting this error:
I am getting this error:
Initialized empty Git repository in /server/user/git@example.com:root/test.git/.git/
fatal: ‘user’ does not appear to be a git repository
fatal: The remote end hung up unexpectedly
It’s a private repository, and I have added my SSH keys.
7 Answers 7
It looks like there’s not a straightforward solution for HTTPS-based cloning regarding GitLab. Therefore if you want a SSH-based cloning, you should take account these three forthcoming steps:
Create properly an SSH key using your email used to sign up. I would use the default filename to key for Windows. Don’t forget to introduce a password!
Copy and paste all content from the recently id_rsa.pub generated into Setting>SSH keys>Key from your GitLab profile.
Get locally connected:
Finally, clone any private or internal GitLab repository!
/.ssh/id_ed25519 myusername@git.mysuborga.myorga.com (or use «$PWD» instead of «
«) because I added my public key only to the chosen sub-orga’s account at GitLab, not to GitLab as a whole. I do not even have a general GitLab user account with the same username. And «ed25519» is the standard of ssh key pair nowadays. And I had to add the output of ssh-keyscan myusername@git.mysuborga.myorga.com to
/.ssh/known_hosts to suppress the warning The authenticity of host [xyz] can’t be established.
You have your ssh clone statement wrong: git clone username git@example.com:root/test.git
You want to leave out username :
If you’re trying this with GitHub, you can do this with your SSH entered:
Once added run the above command. It will prompt for your gitlab username and password and on authentication, it will be cloned.
/.ssh then my clone command worked.
I tried all of these suggestions. Here’s what finally worked for me:
If you are using Windows,
make a folder and open git bash from there
git clone git@gitlab.com:Example/projectName.git
Not the answer you’re looking for? Browse other questions tagged git github gitlab or ask your own question.
Linked
Related
Hot Network Questions
Subscribe to RSS
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
site design / logo © 2021 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2021.12.22.41046
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.