Name already in use
gitlabhq / doc / gitlab-basics / start-using-git.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Command line Git (FREE)
Git is an open-source distributed version control system. GitLab is built on top of Git.
You can do many Git operations directly in GitLab. However, the command line is required for advanced tasks, like fixing complex merge conflicts or rolling back commits.
If you’re new to Git and want to learn by working in your own project, learn how to make your first commit.
For a quick reference of Git commands, download a Git Cheat Sheet.
For more information about the advantages of working with Git and GitLab:
- Watch the GitLab Source Code Management Walkthrough video.
- Learn how GitLab became the backbone of the Worldline development environment.
To help you visualize what you’re doing locally, you can install a Git GUI app.
Choose a terminal
To execute Git commands on your computer, you must open a terminal (also known as command prompt, command shell, and command line). Here are some options:
- For macOS users:
- Built-in Terminal. Press ⌘ command + space and type terminal . . You can integrate it with Zsh and Oh My Zsh for color highlighting and other advanced features.
- Built-in command line. On the Windows taskbar, select the search icon and type cmd . .
- Git Bash. It is built into Git for Windows.
- Built-in Linux Terminal.
Confirm Git is installed
You can determine if Git is already installed on your computer by opening a terminal and running this command:
If Git is installed, the output is:
If your computer doesn’t recognize git as a command, you must install Git.
To start using Git from your computer, you must enter your credentials to identify yourself as the author of your work. The username and email address should match the ones you use in GitLab.
In your shell, add your user name:
Add your email address:
To check the configuration, run:
The —global option tells Git to always use this information for anything you do on your system. If you omit —global or use —local , the configuration applies only to the current repository.
You can read more on how Git manages configurations in the Git configuration documentation.
Choose a repository
Before you begin, choose the repository you want to work in. You can use any project you have permission to access on GitLab.com or any other GitLab instance.
To use the repository in the examples on this page:
- Go to https://gitlab.com/gitlab-tests/sample-project/.
- In the upper-right corner, select Fork.
- Choose a namespace for your fork.
The project becomes available at https://gitlab.com/<your-namespace>/sample-project/ .
You can fork any project you have access to.
Clone a repository
When you clone a repository, the files from the remote repository are downloaded to your computer, and a connection is created.
This connection requires you to add credentials. You can either use SSH or HTTPS. SSH is recommended.
Clone with SSH when you want to authenticate only one time.
Authenticate with GitLab by following the instructions in the SSH documentation.
Go to your project’s landing page and select Clone. Copy the URL for Clone with SSH.
Open a terminal and go to the directory where you want to clone the files. Git automatically creates a folder with the repository name and downloads the files there.
Run this command:
To view the files, go to the new directory:
Clone with HTTPS
Clone with HTTPS when you want to authenticate each time you perform an operation between your computer and GitLab.
Go to your project’s landing page and select Clone. Copy the URL for Clone with HTTPS.
Open a terminal and go to the directory where you want to clone the files.
Run the following command. Git automatically creates a folder with the repository name and downloads the files there.
GitLab requests your username and password.
If you have enabled two-factor authentication (2FA) on your account, you cannot use your account password. Instead, you can do one of the following:
-
with read_repository or write_repository permissions.
- Install Git Credential Manager.
If you have not enabled 2FA, use your account password.
To view the files, go to the new directory:
NOTE: On Windows, if you enter your password incorrectly multiple times and an Access denied message appears, add your namespace (username or group) to the path: git clone https://namespace@gitlab.com/gitlab-org/gitlab.git .
Clone using a token
Clone with HTTPS using a token if:
- You want to use 2FA.
- You want to have a revocable set of credentials scoped to one or more repositories.
You can use any of these tokens to authenticate when cloning over HTTPS:
Convert a local directory into a repository
You can initialize a local folder so Git tracks it as a repository.
Open the terminal in the directory you’d like to convert.
Run this command:
A .git folder is created in your directory. This folder contains Git records and configuration files. You should not edit these files directly.
Add the path to your remote repository so Git can upload your files into the correct project.
You add a «remote» to tell Git which remote repository in GitLab is tied to the specific local folder on your computer. The remote tells Git where to push or pull from.
To add a remote to your local copy:
In GitLab, create a project to hold your files.
Visit this project’s homepage, scroll down to Push an existing folder, and copy the command that starts with git remote add .
On your computer, open the terminal in the directory you’ve initialized, paste the command you copied, and press enter :
View your remote repositories
To view your remote repositories, type:
The -v flag stands for verbose.
Download the latest changes in the project
To work on an up-to-date copy of the project, you pull to get all the changes made by users since the last time you cloned or pulled the project. Replace <name-of-branch> with the name of your default branch to get the main branch code, or replace it with the branch name of the branch you are currently working in.
When you clone a repository, REMOTE is typically origin . This is where the repository was cloned from, and it indicates the SSH or HTTPS URL of the repository on the remote server. <name-of-branch> is usually the name of your default branch, but it may be any existing branch. You can create additional named remotes and branches as necessary.
You can learn more on how Git manages remote repositories in the Git Remote documentation.
A branch is a copy of the files in the repository at the time you create the branch. You can work in your branch without affecting other branches. When you’re ready to add your changes to the main codebase, you can merge your branch into the default branch, for example, main .
Use branches when you:
- Want to add code to a project but you’re not sure if it works properly.
- Are collaborating on the project with others, and don’t want your work to get mixed up.
A new branch is often called feature branch to differentiate from the default branch.
Create a branch
To create a feature branch:
Branch names cannot contain empty spaces and special characters. Use only lowercase letters, numbers, hyphens ( — ), and underscores ( _ ).
Switch to a branch
All work in Git is done in a branch. You can switch between branches to see the state of the files and work in that branch.
To switch to an existing branch:
For example, to change to the main branch:
To view the differences between your local unstaged changes and the latest version that you cloned or pulled:
View the files that have changes
When you add, change, or delete files or folders, Git knows about the changes. To check which files have been changed:
Add and commit local changes
When you type git status , locally changed files are shown in red. These changes may be new, modified, or deleted files or folders.
To stage a file for commit:
Repeat step 1 for each file or folder you want to add. Or, to stage all files in the current directory and subdirectory, type git add . .
Confirm that the files have been added to staging:
The files should be displayed in green text.
To commit the staged files:
Stage and commit all changes
As a shortcut, you can add all local changes to staging and commit them with one command:
Send changes to GitLab.com
To push all local changes to the remote repository:
For example, to push your local commits to the main branch of the origin remote:
Sometimes Git does not allow you to push to a repository. Instead, you must force an update.
Delete all changes in the branch
To discard all changes to tracked files:
This action removes changes to files, not the files themselves. Untracked (new) files do not change.
Unstage all changes that have been added to the staging area
To unstage (remove) all files that have not been committed:
Undo most recent commit
To undo the most recent commit:
This action leaves the changed files and folders unstaged in your local repository.
WARNING: A Git commit should not be reversed if you already pushed it to the remote repository. Although you can undo a commit, the best option is to avoid the situation altogether by working carefully.
You can learn more about the different ways Git can undo changes in the Git Undoing Things documentation.
Merge a branch with default branch
When you are ready to add your changes to the default branch, you merge the feature branch into it:
In GitLab, you typically use a merge request to merge your changes, instead of using the command line.
To create a merge request from a fork to an upstream repository, see the forking workflow.
Advanced use of Git through the command line
For an introduction of more advanced Git techniques, see Git rebase, force-push, and merge conflicts.
Synchronize changes in a forked repository with the upstream
To create a copy of a repository in your namespace, you fork it. Changes made to your copy of the repository are not automatically synchronized with the original. To keep the project in sync with the original project, you need to pull from the original repository.
You must create a link to the remote repository to pull changes from the original repository. It is common to call this remote repository the upstream .
You can now use the upstream as a <remote> to pull new updates from the original repository, and use the origin to push local changes and create merge requests.
Git для начинающих. Урок 2.
Создание и клонирование репозитория
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Что такое репозиторий
Это каталог в файловой системе, где хранится информация о проекте:
- файлы и папки проекта
- история проекта
- настройки проекта
- служебная информация
Информация о репозитории хранится в скрытой папке .git в корне проекта.
Можно ли работать с git локально
Да, можно. Но при этом проект находится только на нашей машине и в случае поломки железа или случайной потери данных мы не сможем восстановить проект.
Локальный репозиторий
Это репозиторий, который хранится на нашей машине, в рабочей папке проекта. Это та самая скрытая папка .git
Удаленный репозиторий, зачем он нужен
Это репозиторий, который хранится в облаке, на сторонних сервисах, специально созданных под работу с проектами git.
Плюсы удаленного репозитория
- выполняет роль резервной копии
- возможность работать в команде
- некоторые дополнительные возможности, которые предоставляет хостинг. Например, визуализация истории или возможность работать над проектом прямо в веб-интерфейсе
Что такое клонирование
Это копирование удаленного репозитория на локальную машину. Обычно это первое действие при работе с проектом. При клонировании на нашу машину копируются файлы и папки проекта и вся его история. То есть мы получаем доступ к истории не с момента начала нашей работы над проектом, а с самого начала проекта.
Как клонировать готовый проект
В первую очередь, нужно получить ссылку на проект. Мы можем найти ее сами или получим готовую, например, на новой работе. Возьмем для примера репозиторий vuejs — https://github.com/vuejs/vue.git
Наберем в командной строке
При этом в текущем каталоге создастся папка vue, в ней окажутся все файлы проекта vue и специальная скрытая папка .git, то есть сам репозиторий, или информация о нем.
Как клонировать проект в другую папку
При клонировании по умолчанию создается папка с таким же названием, как и у репозитория. Но можно склонировать репозиторий и в другую папку вот так
Где vue-new — нужное название папки.
Свой удаленный репозиторий
Для своих проектов нам понадобится собственный репозиторий. Можно работать и локально, но плюсы удаленного мы уже рассматривали выше. Теперь нужно выбрать хостинг для наших git-проектов.
Где держать репозиторий
Есть множество вариантов, самые известные — это github и bitbucket. Нужно выбирать.
На самом деле не парьтесь. У них схожий функционал, и в начале работы с git мы не заметим разницы. bitbucket мне нравится больше из-за интерфейса, но в уроках выберем github из-за его большей популярности.
Чтобы продолжить уроки, нужно зарегистрироваться на github. Если у вас нет там аккаунта, то форму регистрации увидите сразу на главной странице — https://github.com/
Как создать репозиторий в github
После регистрации создание репозитория доступно с главной страницы github. При создании нужно указать название проекта и тип (публичный или приватный). На остальное пока не обращаем внимания.
Права на репозиторий, публичные и приватные
Есть 2 типа репозиториев:
- публичный (public), открыт всем
- приватный (private), доступен только определенному кругу лиц — в первую очередь, нам самим
Публичные репозитории хороши для opensource-проектов и чтобы показать в резюме. Пока нам это не нужно.
Для себя будем создавать приватные репозитории. Для этого нам понадобятся ssh-ключи.
Что такое ssh-ключи
ssh-ключи используются для идентификации клиента на сервере при подключении по безопасному ssh-протоколу. Другими словами, ssh-ключ нужен для того, чтобы пускать на сервер только определенных клиентов. Только тех, кому разрешен доступ к проекту.
ssh-ключ не имеет прямого отношения к git, но так репозитории находятся на удаленных серверах, то ssh-ключи используются для разграничения доступа к приватным репозиториям.
ssh-ключ состоит из пары ключей: публичного и приватного ключа. Это просто 2 текстовых файла:
- /домашний-каталог/.ssh/id_rsa.pub — публичный
- /домашний-каталог/.ssh/id_rsa — приватный
Публичный ключ передается сторонним серверам, например, github, для открытия доступа на эти сервера. Приватный ключ хранится только на нашей машине и никому не передается. То есть когда у нас просят ssh-ключ, чтобы дать доступ на какой-нибудь сервер, мы отдаем именно публичный ключ, id_rsa.pub
Как сгенерировать ssh-ключ
ssh-ключи сами собой не появляются, но стоит проверить, возможно, они были установлены раньше. Запустим в терминале команды
Если видим файлы id_rsa и id_rsa.pub — отлично, ключи уже есть.
Если этих файлов нет, то нужно сгенерировать ключи утилитой ssh-keygen. В Windows она устанавливается вместе с git, в Linux и MacOS при необходимости установите. В Linux, например, вот так
После этого нужно сгенерировать пару ключей, запустив команду в терминале
Появились файлы id_rsa и id_rsa.pub — значит, ключи успешно сгенерированы.
known_hosts — это файл, в котором ssh прописывает сервера, на которые мы заходим. При первом подключении к github нужно будет разрешить доступ к github.com (напечатать yes в терминале)
Как добавить ssh-ключ в настройках github
Открываем публичный ключ id_rsa.pub и копируем его содержимое. В настройках github ищем раздел «SSH и GPG keys» — https://github.com/settings/keys. Жмем «New SSH key», задаем название ключа, например, имя, и вставляем форму публичный ключ, прямо текстом. Все, теперь у нас есть доступ к нашим приватным репозиториям.
Два способа создания проекта
Первый, когда мы начинаем новый проект. Удобнее будет создать репозиторий на github и склонировать пустой проект на локальную машину.
Второй, когда у нас уже есть проект. Нужно зайти в папку проекта и связать его с уже существующим репозиторием на github. Это называется инициализация.
Рассмотрим оба способа.
Пустой проект
Создаем приватный репозиторий на github, назовем его first-site. Я зарегистрировался под именем Webdevkin, моя ссылка для клонирования будет такая — git@github.com:Webdevkin/first-site.git. Ваша зависит от имени пользователя.
Идем в командную строку и запускаем
В текущей папке получим новую папку с названием first-site — это и есть наш проект.
P.S. У вас склонировать этот репозиторий не получится — он закрытый. Создайте свой 🙂
Непустой проект
Допустим, у нас на локальной машине уже есть проект second-site. Создаем в github репозиторий second-site. Заходим в папку проекта и выполняем команды
Все, можно приступать к работе над проектом. Команды add, commit и push мы разберем в следующих уроках.
Это единственный урок, в котором мы разбирались с тонкостями репозиториев. В дальнейшем будем считать, что репозиторий = проект.
Что могу посоветовать
- github или bitbucket? Для личных проектов неважно, оба сервиса разрешают бесплатно создавать приватные репозитории. Для open source или резюме — github
- не увлекайтесь клонированием в папку со своим названием. Есть шанс запутаться, самому или коллегам
- не путайте публичный и приватный ключи. Отдаем вовне только публичный ключ id_rsa.pub
- при смене рабочей машины можно не генерировать ssh-ключи заново, а скопировать их со старой машины. Тогда не придется заново прописывать новые ключи на серверах
Немного подробнее о копировании ssh-ключей
Как скопировать ssh-ключи с одной машины на другую
Хочу немного затронуть эту тему отдельно. Генерировать ключ на новой машине не обязательно. Но нужно выполнить такие действия
- Скопировать id_rsa и id_rsa.pub со старой машины на новую
- Посмотреть права на файлы, возможно, ключи окажутся слишком «открытыми» для записи и потребуется сменить им права доступа — sudo chmod 700
Ссылки, которые могут пригодиться
- github — https://github.com/
- bitbucket — https://bitbucket.org/
- подробнее об ssh-ключах (en) — connecting-to-github-with-ssh
На этом все. В следующем уроке мы сделаем первые изменения в проекте и начнем понимать, в чем заключается прелесть git.
Start using Git on the command line (FREE)
Git is an open-source distributed version control system. GitLab is built on top of Git.
You can do many Git operations directly in GitLab. However, the command line is required for advanced tasks, like fixing complex merge conflicts or rolling back commits.
For a quick reference of Git commands, download a Git Cheat Sheet.
For more information about the advantages of working with Git and GitLab:
- Watch the GitLab Source Code Management Walkthrough video.
- Learn how GitLab became the backbone of the Worldline development environment.
To help you visualize what you’re doing locally, you can install a Git GUI app.
Git terminology
If you’re familiar with Git terminology, you might want to skip this section and go directly to prerequisites.
Repository
In GitLab, files are stored in a repository. A repository is similar to how you store files in a folder or directory on your computer.
- A remote repository refers to the files in GitLab.
- A local copy refers to the files on your computer.
Often, the word «repository» is shortened to «repo».
In GitLab, a repository is contained in a project.
When you want to contribute to someone else’s repository, you make a copy of it. This copy is called a fork. The process is called «creating a fork.»
When you fork a repo, you create a copy of the project in your own namespace. You then have write permissions to modify the project files and settings.
For example, you can fork this project, https://gitlab.com/gitlab-tests/sample-project/, into your namespace. You now have your own copy of the repository. You can view the namespace in the URL, for example https://gitlab.com/your-namespace/sample-project/ . Then you can clone the repository to your local machine, work on the files, and submit changes back to the original repository.
Difference between download and clone
To create a copy of a remote repository’s files on your computer, you can either download or clone the repository. If you download it, you cannot sync the repository with the remote repository on GitLab.
Cloning a repository is the same as downloading, except it preserves the Git connection with the remote repository. You can then modify the files locally and upload the changes to the remote repository on GitLab.
Pull and push
After you save a local copy of a repository and modify the files on your computer, you can upload the changes to GitLab. This is referred to as pushing to the remote, because you use the command git push .
When the remote repository changes, your local copy is behind. You can update your local copy with the new changes in the remote repository. This is referred to as pulling from the remote, because you use the command git pull .
Prerequisites
To start using GitLab with Git, complete the following tasks:
- Create and sign in to a GitLab account.
- Open a terminal.
- Install Git on your computer.
- Configure Git.
- Choose a repository.
Open a terminal
To execute Git commands on your computer, you must open a terminal (also known as command prompt, command shell, and command line). Here are some options:
- For macOS users:
- Built-in Terminal. Press ⌘ command + space and type terminal .
- iTerm2. You can integrate it with zsh and oh my zsh for color highlighting and other advanced features.
- Built-in command line. On the Windows taskbar, select the search icon and type cmd .
- PowerShell.
- Git Bash. It is built into Git for Windows.
- Built-in Linux Terminal.
Install Git
Determine if Git is already installed on your computer by opening a terminal and running this command:
If Git is installed, the output is:
If your computer doesn’t recognize git as a command, you must install Git. After you install Git, run git —version to confirm that it installed correctly.
Configure Git
To start using Git from your computer, you must enter your credentials to identify yourself as the author of your work. The username and email address should match the ones you use in GitLab.
In your shell, add your user name:
Add your email address:
To check the configuration, run:
The —global option tells Git to always use this information for anything you do on your system. If you omit —global or use —local , the configuration applies only to the current repository.
You can read more on how Git manages configurations in the Git configuration documentation.
Choose a repository
Before you begin, choose the repository you want to work in. You can use any project you have permission to access on GitLab.com or any other GitLab instance.
To use the repository in the examples on this page:
- Go to https://gitlab.com/gitlab-tests/sample-project/.
- In the top right, select Fork.
- Choose a namespace for your fork.
The project becomes available at https://gitlab.com/<your-namespace>/sample-project/ .
You can fork any project you have access to.
Clone a repository
When you clone a repository, the files from the remote repository are downloaded to your computer, and a connection is created.
This connection requires you to add credentials. You can either use SSH or HTTPS. SSH is recommended.
Clone with SSH
Clone with SSH when you want to authenticate only one time.
Authenticate with GitLab by following the instructions in the SSH documentation.
Go to your project’s landing page and select Clone. Copy the URL for Clone with SSH.
Open a terminal and go to the directory where you want to clone the files. Git automatically creates a folder with the repository name and downloads the files there.
Run this command:
To view the files, go to the new directory:
Clone with HTTPS
Clone with HTTPS when you want to authenticate each time you perform an operation between your computer and GitLab.
Go to your project’s landing page and select Clone. Copy the URL for Clone with HTTPS.
Open a terminal and go to the directory where you want to clone the files.
Run the following command. Git automatically creates a folder with the repository name and downloads the files there.
GitLab requests your username and password:
- If you have 2FA enabled for your account, you must use a Personal Access Token with read_repository or write_repository permissions instead of your account’s password.
- If you don’t have 2FA enabled, use your account’s password.
To view the files, go to the new directory:
NOTE: On Windows, if you enter your password incorrectly multiple times and an Access denied message appears, add your namespace (username or group) to the path: git clone https://namespace@gitlab.com/gitlab-org/gitlab.git .
Convert a local directory into a repository
You can initialize a local folder so Git tracks it as a repository.
Open the terminal in the directory you’d like to convert.
Run this command:
A .git folder is created in your directory. This folder contains Git records and configuration files. You should not edit these files directly.
Add the path to your remote repository so Git can upload your files into the correct project.
Add a remote
You add a «remote» to tell Git which remote repository in GitLab is tied to the specific local folder on your computer. The remote tells Git where to push or pull from.
To add a remote to your local copy:
In GitLab, create a project to hold your files.
Visit this project’s homepage, scroll down to Push an existing folder, and copy the command that starts with git remote add .
On your computer, open the terminal in the directory you’ve initialized, paste the command you copied, and press enter :
View your remote repositories
To view your remote repositories, type:
The -v flag stands for verbose.
Download the latest changes in the project
To work on an up-to-date copy of the project, you pull to get all the changes made by users since the last time you cloned or pulled the project. Replace <name-of-branch> with the name of your default branch to get the main branch code, or replace it with the branch name of the branch you are currently working in.
When you clone a repository, REMOTE is typically origin . This is where the repository was cloned from, and it indicates the SSH or HTTPS URL of the repository on the remote server. <name-of-branch> is usually the name of your default branch, but it may be any existing branch. You can create additional named remotes and branches as necessary.
You can learn more on how Git manages remote repositories in the Git Remote documentation.
Branches
A branch is a copy of the files in the repository at the time you create the branch. You can work in your branch without affecting other branches. When you’re ready to add your changes to the main codebase, you can merge your branch into the default branch, for example, main .
Use branches when you:
- Want to add code to a project but you’re not sure if it works properly.
- Are collaborating on the project with others, and don’t want your work to get mixed up.
A new branch is often called feature branch to differentiate from the default branch.
Create a branch
To create a feature branch:
Branch names cannot contain empty spaces and special characters. Use only lowercase letters, numbers, hyphens ( — ), and underscores ( _ ).
Switch to a branch
All work in Git is done in a branch. You can switch between branches to see the state of the files and work in that branch.
To switch to an existing branch:
For example, to change to the main branch:
View differences
To view the differences between your local unstaged changes and the latest version that you cloned or pulled:
View the files that have changes
When you add, change, or delete files or folders, Git knows about the changes. To check which files have been changed:
Add and commit local changes
When you type git status , locally changed files are shown in red. These changes may be new, modified, or deleted files or folders.
To stage a file for commit:
Repeat step 1 for each file or folder you want to add. Or, to stage all files in the current directory and subdirectory, type git add . .
Confirm that the files have been added to staging:
The files should be displayed in green text.
To commit the staged files:
Stage and commit all changes
As a shortcut, you can add all local changes to staging and commit them with one command:
Send changes to GitLab.com
To push all local changes to the remote repository:
For example, to push your local commits to the main branch of the origin remote:
Sometimes Git does not allow you to push to a repository. Instead, you must force an update.
Delete all changes in the branch
To discard all changes to tracked files:
This action removes changes to files, not the files themselves. Untracked (new) files do not change.
Unstage all changes that have been added to the staging area
To unstage (remove) all files that have not been committed:
Undo most recent commit
To undo the most recent commit:
This action leaves the changed files and folders unstaged in your local repository.
WARNING: A Git commit should not be reversed if you already pushed it to the remote repository. Although you can undo a commit, the best option is to avoid the situation altogether by working carefully.
You can learn more about the different ways Git can undo changes in the Git Undoing Things documentation.
Merge a branch with default branch
When you are ready to add your changes to the default branch, you merge the feature branch into it:
In GitLab, you typically use a merge request to merge your changes, instead of using the command line.
To create a merge request from a fork to an upstream repository, see the forking workflow.
Advanced use of Git through the command line
For an introduction of more advanced Git techniques, see Git rebase, force-push, and merge conflicts.
Synchronize changes in a forked repository with the upstream
To create a copy of a repository in your namespace, you fork it. Changes made to your copy of the repository are not automatically synchronized with the original. To keep the project in sync with the original project, you need to pull from the original repository.
You must create a link to the remote repository to pull changes from the original repository. It is common to call this remote repository the upstream .
You can now use the upstream as a <remote> to pull new updates from the original repository, and use the origin to push local changes and create merge requests.
How can I clone a private GitLab repository?
It’s a private repository, and I have added my SSH keys.
8 Answers 8
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! (tip: you can skip this step if you already have one ssh key here)