How to use git clone on windows

-l

--local

When the repository to clone from is on a local machine,
this flag bypasses the normal «Git aware» transport
mechanism and clones the repository by making a copy of
HEAD and everything under objects and refs directories.
The files under .git/objects/ directory are hardlinked
to save space when possible.

If the repository is specified as a local path (e.g., /path/to/repo),
this is the default, and --local is essentially a no-op. If the
repository is specified as a URL, then this flag is ignored (and we
never use the local optimizations). Specifying --no-local will
override the default when /path/to/repo is given, using the regular
Git transport instead.

If the repository’s $GIT_DIR/objects has symbolic links or is a
symbolic link, the clone will fail. This is a security measure to
prevent the unintentional copying of files by dereferencing the symbolic
links.

This option does not work with repositories owned by other users for security
reasons, and --no-local must be specified for the clone to succeed.

NOTE: this operation can race with concurrent modification to the
source repository, similar to running cp -r <src> <dst> while modifying
<src>.

--no-hardlinks

Force the cloning process from a repository on a local
filesystem to copy the files under the .git/objects
directory instead of using hardlinks. This may be desirable
if you are trying to make a back-up of your repository.

-s

--shared

When the repository to clone is on the local machine,
instead of using hard links, automatically setup
.git/objects/info/alternates to share the objects
with the source repository. The resulting repository
starts out without any object of its own.

NOTE: this is a possibly dangerous operation; do not use
it unless you understand what it does. If you clone your
repository using this option and then delete branches (or use any
other Git command that makes any existing commit unreferenced) in the
source repository, some objects may become unreferenced (or dangling).
These objects may be removed by normal Git operations (such as git commit)
which automatically call git maintenance run --auto. (See
git-maintenance[1].) If these objects are removed and were referenced
by the cloned repository, then the cloned repository will become corrupt.

Note that running git repack without the --local option in a repository
cloned with --shared will copy objects from the source repository into a pack
in the cloned repository, removing the disk space savings of clone --shared.
It is safe, however, to run git gc, which uses the --local option by
default.

If you want to break the dependency of a repository cloned with --shared on
its source repository, you can simply run git repack -a to copy all
objects from the source repository into a pack in the cloned repository.

--reference[-if-able] <repository>

If the reference <repository> is on the local machine,
automatically setup .git/objects/info/alternates to
obtain objects from the reference <repository>. Using
an already existing repository as an alternate will
require fewer objects to be copied from the repository
being cloned, reducing network and local storage costs.
When using the --reference-if-able, a non existing
directory is skipped with a warning instead of aborting
the clone.

NOTE: see the NOTE for the --shared option, and also the
--dissociate option.

--dissociate

Borrow the objects from reference repositories specified
with the --reference options only to reduce network
transfer, and stop borrowing from them after a clone is made
by making necessary local copies of borrowed objects. This
option can also be used when cloning locally from a
repository that already borrows objects from another
repository—​the new repository will borrow objects from the
same repository, and this option can be used to stop the
borrowing.

-q

--quiet

Operate quietly. Progress is not reported to the standard
error stream.

-v

--verbose

Run verbosely. Does not affect the reporting of progress status
to the standard error stream.

--progress

Progress status is reported on the standard error stream
by default when it is attached to a terminal, unless --quiet
is specified. This flag forces progress status even if the
standard error stream is not directed to a terminal.

--server-option=<option>

Transmit the given string to the server when communicating using
protocol version 2. The given string must not contain a NUL or LF
character. The server’s handling of server options, including
unknown ones, is server-specific.
When multiple --server-option=<option> are given, they are all
sent to the other side in the order listed on the command line.
When no --server-option=<option> is given from the command
line, the values of configuration variable remote.<name>.serverOption
are used instead.

-n

--no-checkout

No checkout of HEAD is performed after the clone is complete.

--[no-]reject-shallow

Fail if the source repository is a shallow repository.
The clone.rejectShallow configuration variable can be used to
specify the default.

--bare

Make a bare Git repository. That is, instead of
creating <directory> and placing the administrative
files in <directory>/.git, make the <directory>
itself the $GIT_DIR. This obviously implies the --no-checkout
because there is nowhere to check out the working tree.
Also the branch heads at the remote are copied directly
to corresponding local branch heads, without mapping
them to refs/remotes/origin/. When this option is
used, neither remote-tracking branches nor the related
configuration variables are created.

--sparse

Employ a sparse-checkout, with only files in the toplevel
directory initially being present. The
git-sparse-checkout[1] command can be used to grow the
working directory as needed.

--filter=<filter-spec>

Use the partial clone feature and request that the server sends
a subset of reachable objects according to a given object filter.
When using --filter, the supplied <filter-spec> is used for
the partial clone filter. For example, --filter=blob:none will
filter out all blobs (file contents) until needed by Git. Also,
--filter=blob:limit=<size> will filter out all blobs of size
at least <size>. For more details on filter specifications, see
the --filter option in git-rev-list[1].

--also-filter-submodules

Also apply the partial clone filter to any submodules in the repository.
Requires --filter and --recurse-submodules. This can be turned on by
default by setting the clone.filterSubmodules config option.

--mirror

Set up a mirror of the source repository. This implies --bare.
Compared to --bare, --mirror not only maps local branches of the
source to local branches of the target, it maps all refs (including
remote-tracking branches, notes etc.) and sets up a refspec configuration such
that all these refs are overwritten by a git remote update in the
target repository.

-o <name>

--origin <name>

Instead of using the remote name origin to keep track of the upstream
repository, use <name>. Overrides clone.defaultRemoteName from the
config.

-b <name>

--branch <name>

Instead of pointing the newly created HEAD to the branch pointed
to by the cloned repository’s HEAD, point to <name> branch
instead. In a non-bare repository, this is the branch that will
be checked out.
--branch can also take tags and detaches the HEAD at that commit
in the resulting repository.

--revision=<rev>

Create a new repository, and fetch the history leading to the given
revision <rev> (and nothing else), without making any remote-tracking
branch, and without making any local branch, and detach HEAD to
<rev>. The argument can be a ref name (e.g. refs/heads/main or
refs/tags/v1.0) that peels down to a commit, or a hexadecimal object
name.
This option is incompatible with --branch and --mirror.

-u <upload-pack>

--upload-pack <upload-pack>

When given, and the repository to clone from is accessed
via ssh, this specifies a non-default path for the command
run on the other end.

--template=<template-directory>

Specify the directory from which templates will be used;
(See the «TEMPLATE DIRECTORY» section of git-init[1].)

-c <key>=<value>

--config <key>=<value>

Set a configuration variable in the newly-created repository;
this takes effect immediately after the repository is
initialized, but before the remote history is fetched or any
files checked out. The <key> is in the same format as expected by
git-config[1] (e.g., core.eol=true). If multiple
values are given for the same key, each value will be written to
the config file. This makes it safe, for example, to add
additional fetch refspecs to the origin remote.

Due to limitations of the current implementation, some configuration
variables do not take effect until after the initial fetch and checkout.
Configuration variables known to not take effect are:
remote.<name>.mirror and remote.<name>.tagOpt. Use the
corresponding --mirror and --no-tags options instead.

--depth <depth>

Create a shallow clone with a history truncated to the
specified number of commits. Implies --single-branch unless
--no-single-branch is given to fetch the histories near the
tips of all branches. If you want to clone submodules shallowly,
also pass --shallow-submodules.

--shallow-since=<date>

Create a shallow clone with a history after the specified time.

--shallow-exclude=<ref>

Create a shallow clone with a history, excluding commits
reachable from a specified remote branch or tag. This option
can be specified multiple times.

--[no-]single-branch

Clone only the history leading to the tip of a single branch,
either specified by the --branch option or the primary
branch remote’s HEAD points at.
Further fetches into the resulting repository will only update the
remote-tracking branch for the branch this option was used for the
initial cloning. If the HEAD at the remote did not point at any
branch when --single-branch clone was made, no remote-tracking
branch is created.

--[no-]tags

Control whether or not tags will be cloned. When --no-tags is
given, the option will be become permanent by setting the
remote.<remote>.tagOpt=--no-tags configuration. This ensures that
future git pull and git fetch won’t follow any tags. Subsequent
explicit tag fetches will still work (see git-fetch[1]).

By default, tags are cloned and passing --tags is thus typically a
no-op, unless it cancels out a previous --no-tags.

Can be used in conjunction with --single-branch to clone and
maintain a branch with no references other than a single cloned
branch. This is useful e.g. to maintain minimal clones of the default
branch of some repository for search indexing.

--recurse-submodules[=<pathspec>]

After the clone is created, initialize and clone submodules
within based on the provided <pathspec>. If no =<pathspec> is
provided, all submodules are initialized and cloned.
This option can be given multiple times for pathspecs consisting
of multiple entries. The resulting clone has submodule.active set to
the provided pathspec, or «.» (meaning all submodules) if no
pathspec is provided.

Submodules are initialized and cloned using their default settings. This is
equivalent to running
git submodule update --init --recursive <pathspec> immediately after
the clone is finished. This option is ignored if the cloned repository does
not have a worktree/checkout (i.e. if any of --no-checkout/-n, --bare,
or --mirror is given)

--[no-]shallow-submodules

All submodules which are cloned will be shallow with a depth of 1.

--[no-]remote-submodules

All submodules which are cloned will use the status of the submodule’s
remote-tracking branch to update the submodule, rather than the
superproject’s recorded SHA-1. Equivalent to passing --remote to
git submodule update.

--separate-git-dir=<git-dir>

Instead of placing the cloned repository where it is supposed
to be, place the cloned repository at the specified directory,
then make a filesystem-agnostic Git symbolic link to there.
The result is Git repository can be separated from working
tree.

--ref-format=<ref-format>

Specify the given ref storage format for the repository. The valid values are:

• files for loose files with packed-refs. This is the default.

• reftable for the reftable format. This format is experimental and its
  internals are subject to change.

-j <n>

--jobs <n>

The number of submodules fetched at the same time.
Defaults to the submodule.fetchJobs option.

<repository>

The (possibly remote) <repository> to clone from. See the
GIT URLS section below for more information on specifying
repositories.

<directory>

The name of a new directory to clone into. The «humanish»
part of the source repository is used if no <directory> is
explicitly given (repo for /path/to/repo.git and foo
for host.xz:foo/.git). Cloning into an existing directory
is only allowed if the directory is empty.

--bundle-uri=<uri>

Before fetching from the remote, fetch a bundle from the given
<uri> and unbundle the data into the local repository. The refs
in the bundle will be stored under the hidden refs/bundle/*
namespace. This option is incompatible with --depth,
--shallow-since, and --shallow-exclude.

Задача: форкнуть репозиторий в GitHub, создать ветку и работать с кодом.

Картинка с сайта: htmlacademy.ru

Сразу появляется много вопросов — что такое GitHub, какие для этого нужны команды, зачем, а главное, как всем этим пользоваться? Давайте разберёмся.

Больше из рубрики Git: введение, основные команды, решение проблем.

Когда мы пишем код, мы постоянно туда что-то добавляем, удаляем, и иногда всё может ломаться. Поэтому перед любыми изменениями стоит сделать копию проекта. Если собирать проекты в папки с именами проект1, проект1_финали проект2_доделка, вы быстро запутаетесь и точно что-нибудь потеряете. Поэтому для работы с кодом используют системы контроля версий.

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

Git — самая популярная система контроля версий. С Git можно работать через командную строку (или терминал). В каждой системе своя встроенная программа для работы с командной строкой. В Windows это PowerShell или cmd, а в Linux или macOS — Terminal. Вместо встроенных программ можно использовать любую другую — например, Git Bash в Windows или iTerm2 для macOS.

Как работает терминал: мы вводим команду и получаем ответ компьютера — или всё получилось, или где-то ошибка, или нужно ввести что-то ещё — например, пароль. Поэтому большая часть этой инструкции состоит из команд для терминала. Сначала будет непривычно, но вам понравится.

Но давайте по порядку — установим Git на компьютер.

Устанавливаем и настраиваем Git

Windows. Скачайте Git для Windows, запустите exe-файл, следуйте инструкциям.

macOS. Скачайте Git для macOS и запустите dmg-файл. Если он не запускается, зайдите в Системные настройки — Безопасность и нажмите кнопку Open anyway (Всё равно открыть).

Linux. Установите Git через встроенный менеджер пакетов. Если у вас Ubuntu, используйте команду sudo apt-get install git. Команды для других дистрибутивов можно посмотреть здесь.

Как проверить, что Git установился

Откройте терминал и введите команду

git --version

Если Git установлен, то вы увидите номер версии, например, 2.35.1.

Настраиваем Git

Теперь нужно ввести имя и адрес электронной почты, чтобы ваши действия в Git были подписаны, а ещё для привязки к GitHub.

Добавить имя (введите его внутри кавычек):

git config --global user.name "ваше имя"

Добавить электронную почту (замените email@example.com на вашу почту):

git config --global user.email email@example.com

Опция --global значит, что имя и почта будут использоваться для всех ваших действий в Git. Если вы хотите менять эту информацию для разных проектов, то вводите эти же команды, только без опции --global.

Регистрируемся на GitHub

GitHub (или Гитхаб) — веб-сервис на основе Git, который помогает совместно разрабатывать IT-проекты. На Гитхабе разработчики публикуют свой и редактируют чужой код, комментируют проекты и следят за новостями других пользователей.

Профиль на Гитхабе и все проекты в нём — ваше публичное портфолио разработчика, поэтому нужно завести профиль, если у вас его ещё нет.

1. Зайдите на сайт https://github.com и нажмите кнопку Sign up.
2. Введите имя пользователя (понадобится в дальнейшей работе), адрес электронной почты (такой же, как при настройке Git) и пароль.
3. На почту придёт код активации — введите на сайте.
4. Появится окно с выбором тарифного плана. Если вы пользуетесь Гитхабом для учёбы, то укажите, что профиль нужен только для вас и вы студент.
5. Опросы и выбор интересов можно пропустить.

На этом всё — вы зарегистрировались и у вас есть собственный профиль.

Устанавливаем SSH-ключи

Чтобы получить доступ к проектам на GitHub со своего компьютера и выполнять команды без постоянного ввода пароля, нужно, чтобы сервер вас узнавал. Для этого используются SSH-ключи.

SSH — протокол для безопасного соединения между компьютерами.

SSH-ключ состоит из двух частей — открытого и закрытого ключа. Открытый ключ мы отправляем на сервер. Его можно не прятать от всех и не переживать, что кто-то его украдёт, потому что без закрытого ключа он бесполезен. А вот закрытый ключ — секретная часть, доступ к нему должен быть только у вас. Это важно.

Мы будем подключаться к GitHub по SSH. Это работает так:

1. Вы отправляете какую-то информацию на GitHub, который знает ваш открытый ключ.
2. GitHub по открытому ключу понимает, что вы это вы, и отправляет что-то в ответ.
3. Только вы можете расшифровать этот ответ, потому что только у вас есть подходящий закрытый ключ.

А чтобы подключиться к GitHub с помощью SSH-ключа, сначала нужно его создать.

Проверяем SSH-ключи

Перед созданием нового SSH-ключа проверим, есть ли на компьютере другие ключи. Обычно они лежат в папке с названием .ssh — поэтому посмотрим, есть ли в ней что-то, с помощью команды в терминале:

ls -al ~/.ssh

Если у вас уже есть SSH-ключ, то в списке будут файлы с именами вроде id_rsa.pub, id_ecdsa.pub или id_ed25519.pub. А если терминал ругается, что директории ~/.ssh не существует, значит, у вас нет SSH-ключей. Давайте это исправим.

Создаём новый SSH-ключ

Откройте терминал и скопируйте туда эту команду. Не забудьте подставить в кавычки почту, на которую вы регистрировались на Гитхабе.

ssh-keygen -t ed25519 -C "your_email@example.com"

ed25519 — это алгоритм для генерации ключей. Если ваша система не поддерживает алгоритм ed25519 (и вы увидели ошибку), используйте немного другую команду с алгоритмом rsa:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Терминал спросит, куда сохранить ключ. Если не хотите менять имя файла, которое предлагает терминал, просто нажмите Enter.

> Generating public/private имя-ключа key pair.
> Enter a file in which to save the key (/c/Users/ваш-профиль/.ssh/id_имя-ключа):*[Press enter]*

Теперь нужно добавить пароль, которым будет зашифрован ваш ключ. Это стоит сделать, иначе в дальнейшем могут быть проблемы с настройкой, да и так просто безопаснее.

В результате создаётся новый SSH-ключ, привязанный к вашей электронной почте.

Создание ключа по шагам:

Картинка с сайта: htmlacademy.ru

Добавляем SSH-ключ в ssh-agent

ssh-agent — программа для хранения и управления SSH-ключами. Давайте запустим её и добавим туда наш SSH-ключ. Запускаем командой eval "$(ssh-agent -s)":

eval "$(ssh-agent -s)"

Если в ответ терминал покажет надпись «Agent pid» и число — значит, всё ок, агент запущен.

Теперь добавим наш ключ командой.

ssh-add ~/.ssh/id_ed25519

Если у вашего ключа другое имя, замените название id_ed25519 именем файла с ключом (это правило применяется и дальше в инструкции). Если вы устанавливали пароль на ключ, введите его два раза после ввода команды ssh-add (терминал подскажет, когда это сделать).

Теперь, если всё хорошо, появится надпись Identity added — значит, можно переходить к добавлению ключа на GitHub.

Копируем SSH-ключ

Чтобы добавить ключ на GitHub, нужно сначала его скопировать из вашего файла командой clip. Вы не увидите ключ на экране, но он появится в буфере обмена, и его можно будет вставить на Гитхаб.

clip < ~/.ssh/id_ed25519.pub

Команда clip может не сработать на вашем компьютере, тогда есть два способа узнать ключ — простой и сложный.

Сложный способ. Найдите скрытую папку .ssh, откройте файл id_ed25519.pub в текстовом редакторе и скопируйте его содержимое.

Простой способ. Введите команду ниже и ключ появится прямо в терминале — его нужно вручную скопировать в буфер обмена. Ключ начинается с ssh-ed22519 или ssh-rsa (или похожей строки) — поэтому копируйте строку прямо с самого начала.

~ cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaCZvnr4ax+Fr shklyar@htmlacademy.ru

Не копируйте этот ключ из статьи — он уже не работает.

Добавляем SSH-ключ на GitHub

Это нужно сделать, чтобы GitHub вас узнавал.

Перейдите на страницу для работы с ключами в вашем профиле на GitHub и нажмите кнопку New SSH key.

В поле Title нужно добавить название нового ключа. Например, если вы используете Mac, вы можете назвать ключ MacBook Air, или, если ключ для курсов Академии, то Academy. А ключ, который вы скопировали на прошлом шаге, вставьте в поле Key.

Картинка с сайта: htmlacademy.ru

Не копируйте ключ со скриншота — он уже не работает.

Теперь нажмите кнопку Add SSH key и, если потребуется, введите свой пароль от GitHub, чтобы подтвердить сохранение. Если всё сделано верно, новый ключ появится в списке на странице https://github.com/settings/keys.

Картинка с сайта: htmlacademy.ru

Теперь мы можем поработать с проектом в репозитории.

Что такое репозиторий

Репозиторий — папка с файлами вашего проекта на сервере GitHub. Так вы можете работать с проектом откуда угодно, не переживая, что какие-то файлы потеряются — все данные останутся в репозитории.

Если над проектом работает несколько программистов, сначала создаётся мастер-репозиторий — это общий репозиторий с рабочей версией проекта. А каждый программист работает с форком — то есть полной копией мастер-репозитория. В форке вы можете безнаказанно менять код и не бояться что-то сломать в основной версии проекта.

Делаем форк мастер-репозитория

Заходим в нужный репозиторий и нажимаем на «вилку» с надписью fork.

Картинка с сайта: htmlacademy.ru

Появится окно Create a new fork — проверьте, что он называется так, как вам нужно, и жмите кнопку Create fork. Через пару секунд всё готово.

Картинка с сайта: htmlacademy.ru

Клонируем форк на компьютер — git clone

Клонировать форк — значит скачать его, чтобы работать с кодом на своём компьютере. Тут нам и пригодится SSH.

Открываем терминал и переходим в папку с будущим проектом — для этого используем команду cd your-project. Если вы хотите, чтобы проект лежал в папке device, введите

cd device

Если такой папки на компьютере нет, то сначала введите md your-project, чтобы создать эту папку, а затем cd your-project. Когда перейдёте в папку, введите команду git clone для клонирования репозитория:

git clone git@github.com:your-nickname/your-project.git

Замените your-nickname на ваше имя пользователя на GitHub, а your-project на название проекта. Проще всего их найти прямо наверху страницы репозитория.

Если вы правильно настроили SSH-ключи, Git скопирует репозиторий на ваш компьютер.

➜  device git clone git@github.com:academy-student/1173761-device-34.git
Клонирование в «1173761-device-34»…
remote: Enumerating objects: 15, done.
remote: Counting objects: 100% (15/15), done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 15 (delta 0), reused 15 (delta 0), pack-reused 0
Получение объектов: 100% (15/15), 145.07 КиБ | 900.00 КиБ/с, готово.

Если вы видите ошибку Error: Permission denied (publickey), скорее всего, вы ошиблись в настройке SSH-ключа. Вернитесь в этот раздел инструкции и повторите процесс настройки.

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

git clone git@github.com:_your-nickname_/_your-project_.git folder_name

Теперь на вашем компьютере в папке your_project или в той, название которой вы указали, находится полная копия репозитория c GitHub.

В каждом репозитории есть как минимум одна основная ветка, которую создаёт сам Git — она называется master. Обычно в ней хранят проверенную версию программы без ошибок.

А если вы хотите исправить ошибку в коде или добавить что-то в проект, но не хотите сломать код в основной ветке, нужно создать новую ветку из master и работать из неё. Каждая ветка — что-то вроде второстепенной дороги, которая затем снова соединится с основной.

Создаём новую ветку — git branch

Откройте терминал и введите команду

git branch

Она показывает список веток, с которыми мы работаем в проекте, и выделяет текущую. Если мы находимся в master , то создаём новую ветку командой

git checkout -b имя-новой-ветки.

➜  1173761-device-34 git:(master) git checkout -b task1
Переключено на новую ветку «task1»
➜  1173761-device-34 git:(task1)

Если текущая ветка не master, переключитесь на неё с помощью команды checkout. После git checkout надо указать название нужной ветки.

git checkout master

Мы делаем это, чтобы новая ветка содержала свежую рабочую версию проекта. Если вы ошиблись в названии, например, допустили опечатку, вы можете изменить название ветки с помощью команды:

git branch -m старое-имя-ветки новое-имя-ветки.

Сохраняем изменения — git add

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

Если вы хотите сохранить изменения не во всех файлах, для начала введите команду git status. Она покажет текущее состояние в вашей ветке, а именно список с названиями изменённых файлов, если они есть, и укажет на те, которые ожидают записи и сохранения (обычно они выделены красным цветом).

Картинка с сайта: htmlacademy.ru

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

git add -A

Чтобы сохранить изменения только отдельных файлов, укажите их имена вручную. Например, если вы изменили файл index.html, введите

git add index.html

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

Делаем коммит — git commit

Сделать коммит — значит зафиксировать все сохранённые изменения и дать им название. Это делается с помощью команды commit

git commit -m "ваше сообщение"

Текст сообщения должен быть лаконичным и вместе с этим сообщать о том, что делает коммит (внесённые изменения). Например,

• Добавляет имя наставника в Readme
• Вводит функцию сортировки изображений
• Правит ошибку в поиске городов на карте

Картинка с сайта: htmlacademy.ru

Отправляем изменения на GitHub — git push

Сохранённые изменения пока не видны коллегам, потому что находятся в нашем локальном репозитории. Нужно отправить коммиты на GitHub. Для этого введите команду

git push origin название-текущей-ветки

Где origin означает репозиторий на компьютере, то есть ваш форк. Слово origin — часть команды, не меняйте это название на своё.

Картинка с сайта: htmlacademy.ru

Создаём пулреквест

Пулреквест (или PR) — это предложение изменить код в репозитории. PR должен проверить администратор мастер-репозитория — это может быть коллега-разработчик, техлид или наставник на курсе.

Если к коду нет вопросов, пулреквест принимается. Если нужно что-то исправить — отклоняется, и придётся исправить код и снова пройти цепочку git add — git commit — git push. Если вы и дальше работаете в той же ветке, а пулреквест ещё не принят, все ваши изменения автоматически добавятся в пулреквест, созданный из этой ветки после команды git push origin название-текущей-ветки.

Чтобы создать пулреквест, зайдите на страницу вашего форка на GitHub. Вверху появилась плашка Compare & pull request, а ещё можно зайти на вкладку Pull Requests.

Картинка с сайта: htmlacademy.ru

Нажмите на неё и окажетесь на странице открытия пулреквеста. Проверьте описание и нажмите Create pull request.

Готово, теперь ждём остаётся ждать одобрения пулреквеста или комментариев к нему.

Синхронизируем репозитории

Предположим, вы исправили код, руководитель или наставник одобрил ваши правки и принял пулреквест.

Картинка с сайта: htmlacademy.ru

Теперь код в мастер-репозитории обновился, а в вашем форке нет, вы ведь не обновляли свою версию репозитория с тех пор, как клонировали её себе на компьютер. Приведём форк в актуальное состояние.

В локальном репозитории переключаемся на ветку master.

git checkout master

Забираем изменения из ветки master мастер-репозитория

git pull git@github.com:academy-student/1173761-device-34.git master

Отправляем изменения уже из своей ветки master в ваш форк на GitHub с помощью команды

git push origin master

Готово, теперь форк и оригинальный репозиторий находятся в актуальном состоянии.

Словарик

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

Git — самая популярная система контроля версий. С Git можно работать через терминал.

Как работает терминал: мы вводим команду и получаем ответ компьютера — или всё получилось, или где-то ошибка, или нужно ввести что-то ещё.

GitHub (или Гитхаб) — веб-сервис, основанный на Git, который помогает совместно разрабатывать IT-проекты. На Гитхабе разработчики публикуют свой и редактируют чужой код, комментируют проекты и следят за новостями других пользователей.

SSH-ключ нужен, чтобы получить доступ к проектам на GitHub со своего компьютера и выполнять команды без постоянного ввода пароля, нужно, чтобы сервер нас узнавал.

ssh-agent — программа для хранения и управления SSH-ключами.

Репозиторий — папка с файлами вашего проекта на сервере GitHub или у вас на компьютере.

Мастер-репозиторий — это общий для всей команды репозиторий с рабочей версией проекта.

Форк — полная копия мастер-репозитория, в которой вы можете безопасно работать.

Клонировать форк — скачать его командой git clone, чтобы работать с кодом на своём компьютере.

Пулреквест (или PR) — предложение изменить код в репозитории. PR должен проверить администратор мастер-репозитория — это может быть коллега-разработчик, техлид или наставник на курсе.

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

ТелеграмПодкастБесплатные учебники

Cloning a Git repository is a fundamental skill in software development, enabling developers to work on projects hosted on platforms like GitHub, GitLab, or Bitbucket. When you clone a repository, you create a local copy on your Windows machine, which allows you to make changes, track commits, and collaborate effectively.

In this post, we’ll cover everything you need to know to clone a Git repository on Windows, including installation steps and troubleshooting tips.

Why Clone a Repository?

Cloning a repository gives you a full copy of the project’s history, including all commits, branches, and files, which lets you:

1. Contribute to Open-Source Projects: Easily make and track contributions to collaborative projects.
2. Work Offline: Clone repositories to work on projects even without internet access.
3. Maintain Version Control: Keep a complete record of changes, allowing you to experiment, track, and revert changes when necessary.

Prerequisites

To clone a Git repository on Windows, you need to:

• Install Git: If you haven’t installed Git yet, download it from Git’s official site and follow the installation instructions.
• Have Repository Access: Ensure you have the repository URL and appropriate access permissions if it’s private.

Step 1: Install Git on Windows

If you haven’t installed Git, follow these steps:

1. Download Git from the official website (https://git-scm.com/downloads) and choose the Windows version.
2. Run the Installer and follow the prompts, choosing default options unless you have specific requirements.
3. Once installed, verify the installation by opening a Command Prompt (or Git Bash) and typing:

   git --version

This should display your Git version number, confirming the installation.

Step 2: Open Git Bash or Command Prompt

Git Bash provides a Unix-style command line, but you can also use the Command Prompt or PowerShell on Windows.

• Git Bash: Right-click on your desktop or within any folder, then select Git Bash Here.
• Command Prompt: Open the Start Menu, type cmd, and select Command Prompt.

Either option will work for cloning a repository.

Step 3: Copy the Repository URL

To clone a repository, you need its URL. Here’s how to find it:

1. Go to the repository’s page on GitHub, GitLab, or your chosen Git platform.
2. Click the Code button (often green on GitHub) and select HTTPS, SSH, or GitHub CLI as the protocol.
3. Copy the URL provided. It should look something like this:

• HTTPS: https://github.com/username/repository.git
• SSH: [email protected]:username/repository.git

Note: HTTPS is the easiest option for general users, while SSH is recommended if you’ve set up SSH keys for enhanced security.

Step 4: Navigate to the Desired Directory

Before cloning, decide where you want the cloned repository to be stored on your computer.

1. In Git Bash or Command Prompt, navigate to your desired directory using the cd command. For example:

   cd C:\path\to\your\directory

1. If you want to create a new directory for the repository, you can do so with:

   mkdir new-folder-name
   cd new-folder-name

Step 5: Clone the Repository

Once you’re in the correct directory, use the git clone command followed by the repository URL:

git clone https://github.com/username/repository.git

Replace https://github.com/username/repository.git with the actual URL of your repository. If you’re using SSH, it will look like this:

git clone [email protected]:username/repository.git

Git will now clone the repository, downloading all files and commit history to your local machine.

Tip: If the repository is private, Git will prompt you for your username and password when using HTTPS, or use your SSH key if you chose SSH.

Step 6: Confirm the Clone

After cloning, Git will create a directory with the same name as the repository in your current directory. To verify, navigate into the newly created folder:

cd repository

You can then check the list of files and branches to confirm the clone was successful:

ls   # Use "dir" if you’re in Command Prompt
git branch -a

Example Workflow: Cloning a GitHub Repository to Desktop

To illustrate, let’s walk through an example of cloning a GitHub repository to the Desktop:

1. Open Git Bash: Right-click on the Desktop and select Git Bash Here.
2. Clone the Repository: Use the following command:

   git clone https://github.com/example-user/example-repo.git

1. Navigate into the Repository Folder:

   cd example-repo

1. Confirm the Files:

   ls

You now have a complete local copy of the example-repo repository on your Desktop.

Troubleshooting Common Issues

1. “Permission denied” with SSH: Make sure your SSH key is added to GitHub and is loaded in your SSH agent. Use ssh-add to load the key if necessary.
2. Cloning Private Repositories: If cloning a private repository, ensure you have the correct permissions and are logged in with an authorized account.
3. HTTPS Authentication Failures: When using HTTPS, Git may cache outdated credentials. Run git credential-manager uninstall to clear cached credentials and try again.
4. Proxy Issues: If you’re behind a firewall or proxy, Git may fail to connect. Configure your proxy settings with:

   git config --global http.proxy http://proxyaddress:port

Working with Your Cloned Repository

Once cloned, you can make changes, create new branches, or push commits to the remote repository. Here are some common commands you’ll likely use next:

• Checking Repository Status:

  git status

• Pulling Updates from the Remote Repository:

  git pull

• Creating and Switching Branches:

  git checkout -b new-branch-name

• Pushing Changes to the Remote Repository:

  git push origin branch-name

These commands will allow you to work locally on your repository while keeping it in sync with the remote version.

Final Thoughts

Cloning a Git repository on Windows is a straightforward process once you understand the steps and have the correct tools in place. By following this guide, you can quickly get started with your local copy, enabling you to work on projects, make contributions, and collaborate more effectively. With practice, managing repositories locally and syncing changes with remote repositories will become second nature, helping you streamline your development workflow.

Когда мы клонируем себе репозиторий с GitHub, то не просто скачиваем копию кода с сервера на свой компьютер, а получаем полноценную рабочую среду с историей коммитов, ветками и возможностью синхронизации.

Сегодня разберёмся, как всё это работает, как клонировать себе репозиторий и что делать, если что-то пойдёт не так.

Введение в клонирование репозиториев

Git — это система управления версиями, которая позволяет отслеживать изменения в коде, работать над разными версиями проекта и синхронизировать файлы между несколькими разработчиками.

Репозиторий — это хранилище, в котором находятся файлы проекта, их предыдущие версии и история всех изменений. Он может находиться локально на компьютере или на удалённом сервере, в нашем случае — на GitHub.

Клонирование репозитория — это создание его полной копии на локальном устройстве. В отличие от обычного скачивания, при клонировании загружаются не только файлы, но и вся история изменений, включая коммиты, ветки и удалённые ссылки. После клонирования можно вносить правки, фиксить баги, коммитить изменения и синхронизировать их с удалённым репозиторием.

Можно клонировать как свой репозиторий, так и чужой, если хочется внести свой вклад в опенсорс или просто поэкспериментировать с чужим кодом.

Картинка с сайта: thecode.media

Зачем клонировать репозиторий

Клонирование нужно, если мы хотим работать с кодом локально, изменять файлы и синхронизироваться с удалённым репозиторием. Это полезно в нескольких сценариях:

Клонирование даёт полный контроль над кодом, возможность работы в офлайне и синхронизацию с удалённым репозиторием.

Способы клонирования репозитория

Клонировать репозиторий можно разными способами — через командную строку, графический интерфейс Git GUI или среду разработки. Выбор зависит от удобства и предпочтений:

Клонирование через командную строку

Git CLI (Command Line Interface) — это инструмент для работы с Git через терминал или командную строку. Он позволяет выполнять разные команды — git clone, git commit, git push и другие.

Сначала копируем ссылку на репозиторий с GitHub, затем в терминале используем команду git clone, указывая эту ссылку. После клонирования можно переключаться между ветками, вносить изменения и отправлять их обратно в удалённый репозиторий. Как именно всё это делать — разберём чуть позже.

Клонирование с помощью Git GUI

Если не хочется работать в терминале, можно использовать графические клиенты. Они упрощают работу с Git, показывают изменения наглядно и позволяют клонировать репозитории в несколько кликов.

Самые популярные:

Везде есть кнопка Clone, куда нужно вставить ссылку на репозиторий, выбрать папку для загрузки и нажать ОК.

Картинка с сайта: thecode.media

Клонирование через Visual Studio

В Visual Studio или Visual Studio Code Git уже встроен в редактор. В нём можно клонировать репозиторий прямо из интерфейса:

Картинка с сайта: thecode.media

В Visual Studio (не Code) всё так же:

Удобно, если работаем в Visual Studio и хотим сразу открыть проект после клонирования.

Пошаговая инструкция по клонированию с помощью командной строки

Теперь подробно разберём, как клонировать репозиторий с GitHub на свой компьютер. Начнём с установки Git, зарегистрируемся на GitHub, разберёмся с SSH-ключами и в конце выполним само клонирование. В результате сможем работать с кодом локально, а затем отправлять изменения обратно в репозиторий.

Шаг 1: установка и настройка Git

Прежде чем клонировать репозиторий, нужно убедиться, что установлен Git. В большинстве случаев он уже есть в системе, но если нет, его можно скачать с официального сайта и установить.

Чтобы проверить, установлен ли Git, открываем терминал и вводим команду git --version. Если Git установлен, то увидим его версию.

Картинка с сайта: thecode.media

Дальше нужно настроить имя пользователя и email, которые будут использоваться для коммитов. Для этого используем такую команду, не забудьте заменить имя и почту на свои:

git config --global user.name "Имя"

git config --global user.email "your.email@mail.com"

Эти данные будут отображаться в истории коммитов, так что лучше указать те же, что и в GitHub.

Чтобы посмотреть все глобальные настройки Git, вводим команду git config --list --global. Если нужно изменить какие-то параметры, можно просто снова выполнить команду git config --global и указать новые значения.

Шаг 2: регистрация на GitHub

Если ещё нет аккаунта, регистрируемся на GitHub. Это бесплатно, и базового аккаунта хватит для большинства задач.

После регистрации заходим в настройки профиля: Settings → SSH and GPG keys. Этот раздел понадобится для следующего шага, не закрываем это окошко, пусть повисит немного на фоне.

Картинка с сайта: thecode.media

Шаг 3: создание SSH-ключа

SSH (Secure Shell) — это безопасный способ подключения к репозиторию без необходимости вводить логин и пароль. Если настроить SSH, можно удобно работать с удалёнными репозиториями, не вводя учётные данные при каждом действии.

Для начала проверим, есть ли уже сгенерированные SSH-ключи. Это можно посмотреть либо в профиле GitHub, либо выполнив команду в терминале:

ls -al ~/.ssh

Если в списке есть файлы id_rsa.pub или id_ed25519.pub, значит, SSH-ключи уже созданы, и можно сразу добавить их в GitHub. Если терминал говорит, что такой директории нет, значит, ключи ещё не создавались.

Чтобы создать новый ключ, выполняем команду (и вводим тот же email, который указали при настройке Git):

ssh-keygen -t ed25519 -C "your.email@mail.com"

Терминал сообщит, что создаёт новый ключ, и попросит указать путь для сохранения ключа (по умолчанию ~/.ssh/id_ed25519). Можно нажать Enter, чтобы использовать стандартный путь.

Дальше терминал попросит задать парольную фразу — можно что-то ввести или оставить пустым. Если указать пароль, то при каждом использовании ключа GitHub будет его запрашивать.

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

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Картинка с сайта: thecode.media

Теперь нужно добавить публичный ключ (id_ed25519.pub) в свой профиль GitHub. Для этого копируем ключ в буфер обмена:

cat ~/.ssh/id_ed25519.pub | pbcopy  # для macOS

clip < ~/.ssh/id_ed25519.pub  # для Windows

Переходим в свой профиль GitHub → Settings → SSH and GPG keys и нажимаем New SSH key. Там вводим название (например, «Рабочий ноутбук»), вставляем скопированный ключ в поле Key и нажимаем Add SSH key.

Картинка с сайта: thecode.media

Дальше GitHub попросит ввести пароль от аккаунта, чтобы подтвердить действие. После этого в списке ключей в профиле появится новый Authentication keys.

Теперь проверим, всё ли сработало и установлено ли SSH-соединение. Для этого вводим команду:

ssh -T git@github.com

Если всё ок, то получим сообщение You’ve successfully authenticated, but GitHub does not provide shell access:

Картинка с сайта: thecode.media

Шаг 4: клонирование репозитория

Дальше нам понадобится ссылка на репозиторий и папка, куда мы хотим его склонировать. На GitHub можно выбрать один из двух вариантов:

Допустим, мы хотим склонировать через SSH репозиторий Spoon-Knife. Для этого сначала копируем ссылку на него.

Картинка с сайта: thecode.media

Заходим на страницу репозитория, нажимаем на кнопку Code, выбираем вкладку SSH и копируем оттуда ссылку:

git@github.com:octocat/Spoon-Knife.git

Теперь в терминале переходим в папку, где хотим разместить клонированный проект. Например, если хотим поместить его в ~/projects/, то выполняем:

cd ~/projects/

Затем вводим команду клонирования:

git clone git@github.com:octocat/Spoon-Knife.git

Картинка с сайта: thecode.media

После выполнения команды в выбранной папке появится директория Spoon-Knife:

cd Spoon-Knife
ls -la

Картинка с сайта: thecode.media

Всё! Теперь можно открыть папку с проектом в редакторе кода и начать работу:

Картинка с сайта: thecode.media

Клонированный репозиторий связан с удалённым репозиторием на GitHub, и любые изменения можно коммитить и пушить обратно.

Проблемы и их решения

Иногда при клонировании возникают ошибки доступа, проблемы с аутентификацией или ошибки с URL. Посмотрим, что с этим делать.

Ошибка доступа (401, 403)

Если при клонировании через HTTPS появляется ошибка 401 Unauthorized или 403 Forbidden, это значит, что к репозиторию нет доступа. Тогда нужно:

Как исправить:

Ошибка Repository not found

Эта ошибка возникает, если репозиторий не существует или указана неправильная ссылка.

Как исправить:

Ошибка с SSH-ключом

Если используем SSH, но клонирование не срабатывает, возможно, проблема с ключами.

Как исправить:

Ошибка Remote HEAD refers to nonexistent ref

Если после клонирования Git пишет remote HEAD refers to nonexistent ref, значит, в репозитории удалили основную ветку.

Как исправить:

• Посмотреть доступные ветки:

  git branch -a

• Переключиться на нужную ветку:

  git checkout main

Если ничего не помогает, тогда дальше углубляемся в документацию или идём на StackOverflow ¯\_(ツ)_/¯