Команда git clone 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.

Уровень сложностиСредний

Время на прочтение9 мин

Количество просмотров48K

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

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

Если вам интересен процесс и вы хотите следить за дальнейшими материалами, буду признателен за подписку на мой телеграм-канал. Там я публикую полезныe материалы по разработке, разборы сложных концепций, советы как быть продуктивным и конечно же отборные мемы: https://t.me/nullPointerDotEXE.

git clone

Эта команда используется для создания локальной копии удаленного репозитория. По сути, вы скачиваете всю историю проекта и рабочие файлы с сервера (например, с GitHub, GitLab, Bitbucket) на свой компьютер. Это самая первая команда, которую вы выполняете, когда начинаете работать с существующим проектом. Вы указываете URL репозитория, и Git создает папку с именем репозитория (если не указать другое имя) и загружает туда все необходимое.
Пример:

git clone https://github.com/имя_пользователя/имя_репозитория.git
# Или так, чтобы клонировать в папку с другим именем:
git clone https://github.com/имя_пользователя/имя_репозитория.git моя_папка_проекта

Просто убедитесь, что у вас есть права доступа к репозиторию, если он приватный. И помните, git clone автоматически настраивает связь с удаленным репозиторием под именем origin, что упрощает последующие push и pull.

git status

Ваш главный индикатор состояния репозитория. Эта команда показывает, какие файлы были изменены с момента последнего коммита, какие файлы готовы к коммиту , а какие файлы Git еще не отслеживает. Выполнять git status стоит часто – перед add, перед commit, после pull, чтобы всегда понимать, что происходит в вашем рабочем каталоге. Она не меняет ничего, только информирует.
Пример:

git status

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

git add

Эта команда добавляет изменения из рабочего каталога в так называемую «staging area». Staging area – это промежуточный этап перед созданием коммита. Вы сами выбираете, какие именно изменения войдут в следующий коммит. Это позволяет делать атомарные, логически завершенные коммиты, даже если вы внесли множество разных изменений в разные файлы. Можно добавлять файлы по одному, группами или все сразу.
Примеры:

# Добавить конкретный файл
git add имя_файла.txt

# Добавить все изменения в текущей папке и подпапках
git add .

# Добавить все измененные и новые файлы во всем репозитории
git add -A

# Интерактивно выбрать, какие части изменений в файле добавить
git add -p

Часто используется git add ., но будьте внимательны: эта команда добавит все изменения, включая случайные или временные файлы, если они не указаны в .gitignore. Использование git add -p очень полезно для ревью собственных изменений перед коммитом.

git commit

Фиксирует изменения, добавленные в staging area (git add), в локальной истории репозитория. Каждый коммит — это снимок состояния проекта в определенный момент времени, снабженный уникальным хешем и сообщением, описывающим суть изменений. Хорошее сообщение коммита критически важно для понимания истории проекта вами и вашей командой.
Примеры:

# Создать коммит с коротким сообщением прямо из командной строки
git commit -m "Исправлена опечатка в README"

# Открыть текстовый редактор для ввода подробного сообщения коммита
git commit

Старайтесь писать осмысленные сообщения коммитов. Стандартная практика — начинать с краткой строки (до 50 символов), описывающей суть, а затем, после пустой строки, добавлять более подробное описание, если это необходимо. Если вы забыли что-то добавить в последний коммит, можно использовать git commit --amend, но делайте это только с коммитами, которые еще не были отправлены на удаленный сервер (git push), иначе создадите проблемы коллегам.

git push

Отправляет ваши локальные коммиты на удаленный репозиторий (тот самый origin, который обычно настраивается при git clone). Это делает ваши изменения доступными для других членов команды. Вы указываете имя удаленного репозитория (обычно origin) и имя ветки, которую хотите отправить.
Примеры:

# Отправить изменения из текущей локальной ветки в одноименную ветку на origin
git push origin имя_ветки

# Более короткая версия, если upstream уже настроен (часто работает после первого push)
git push

Перед git push всегда полезно сделать git pull, чтобы убедиться, что ваша локальная версия ветки актуальна и избежать потенциальных конфликтов при отправке. Если Git откажется пушить из-за расхождения историй, вам сначала нужно будет интегрировать эти удаленные изменения (git pull).

git pull

Забирает изменения с удаленного репозитория и пытается слить их с вашей текущей локальной веткой. По сути, это комбинация двух других команд: git fetch (скачивает изменения, но не применяет их) и git merge (сливает скачанные изменения с вашей веткой). Это стандартный способ обновить вашу локальную копию проекта последними изменениями от коллег.
Примеры:

# Скачать изменения из ветки 'main' репозитория 'origin' и слить их с текущей локальной веткой
git pull origin main

# Короткая версия, если upstream настроен для текущей ветки
git pull

Будьте готовы к тому, что git pull может привести к конфликтам слияния, если вы и кто-то другой редактировали одни и те же участки кода в разных коммитах. Git сообщит об этом и отметит конфликтующие места в файлах. Вам нужно будет вручную разрешить эти конфликты, затем добавить (git add) исправленные файлы и завершить слияние (часто это делается новым коммитом). Иногда вместо merge при pull используется rebase (git pull --rebase), что сохраняет историю более линейной.

git branch

Управляет ветками в вашем репозитории. Ветки — это независимые линии разработки, позволяющие работать над новой функциональностью или исправлением ошибок, не затрагивая основной стабильный код (например, в ветке main или master). Команда git branch без аргументов покажет список всех локальных веток и отметит текущую звездочкой.
Примеры:

# Показать все локальные ветки
git branch

# Создать новую ветку с именем 'new-feature'
git branch new-feature

# Удалить ветку (безопасно - не даст удалить, если изменения не слиты)
git branch -d old-feature

# Удалить ветку принудительно (опасно - можно потерять изменения)
git branch -D very-old-feature

# Показать все ветки (локальные и удаленные)
git branch -a

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

git checkout

Эта команда используется для переключения между ветками или восстановления файлов в рабочем каталоге до состояния из определенного коммита или индекса. Это одна из самых многозадачных (и потому иногда путающих) команд в Git. Основное применение — переход на другую ветку для работы над ней.
Примеры:

# Переключиться на существующую ветку 'develop'
git checkout develop

# Создать новую ветку 'hotfix' и сразу переключиться на неё
git checkout -b hotfix

# Отменить изменения в файле 'config.yml' до состояния последнего коммита
git checkout -- config.yml

Использование git checkout -- файл опасно, так как отменяет все незакоммиченные изменения в файле безвозвратно. Будьте уверены, что делаете это намеренно. Из-за многозначности checkout, в новых версиях Git появились команды git switch (для переключения веток) и git restore (для восстановления файлов), которые делают код более читаемым и безопасным. Но checkout всё ещё очень распространён.

git switch

Более современная и безопасная альтернатива git checkout для переключения между ветками. Эта команда создана специально для работы с ветками, что делает намерения в коде более ясными и снижает риск случайной потери данных при восстановлении файлов (так как switch этим не занимается).
Примеры:

# Переключиться на существующую ветку 'feature/auth'
git switch feature/auth

# Создать новую ветку 'bugfix/login-issue' и переключиться на неё
git switch -c bugfix/login-issue

# Вернуться на предыдущую ветку
git switch -

Если вы используете свежую версию Git, рекомендуется отдавать предпочтение git switch для переключения веток вместо git checkout. Это делает ваши скрипты и ручные операции более понятными и менее подверженными ошибкам.

git merge

Сливает изменения из одной ветки в другую. Обычно вы переключаетесь на ветку, в которую хотите влить изменения (например, main или develop), а затем выполняете git merge с указанием ветки, из которой хотите забрать изменения (например, ваша feature ветка). Git попытается автоматически объединить истории.
Пример:

# Переключаемся на основную ветку
git switch main

# Вливаем изменения из ветки 'new-feature' в 'main'
git merge new-feature

Если конфликтов нет, Git создаст новый «коммит слияния» (merge commit), у которого будет два родительских коммита. Если есть конфликты, Git остановит процесс, отметит конфликты в файлах, и вам нужно будет разрешить их вручную, добавить исправленные файлы (git add) и завершить слияние командой git commit. Слияние — ключевой процесс интеграции работы разных разработчиков или разных фич.

git rebase

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

git checkout feature #переключаемся на ветку
git rebase main #так же вливаем изменения

После завершения — git push --force, если история уже была опубликована.

git log

Показывает историю коммитов текущей ветки, начиная с самого последнего. Вы увидите хеш каждого коммита, автора, дату и сообщение коммита. Это основной инструмент для изучения истории проекта, понимания, кто и когда внес определенные изменения. git log имеет множество опций для форматирования вывода.
Примеры:

# Показать стандартный лог
git log

# Показать лог в более компактном виде (одна строка на коммит)
git log --oneline

# Показать лог с графическим представлением веток и слияний
git log --graph --oneline --decorate

# Показать лог изменений для конкретного файла
git log имя_файла.py

# Показать последние 5 коммитов
git log -n 5

Изучение git log и его опций — очень полезный навык. Он помогает не только смотреть историю, но и находить конкретные коммиты, например, чтобы отменить их (git revert) или посмотреть изменения (git show ).

git diff

Показывает разницу между различными состояниями: между рабочим каталогом и индексом (staging area), между индексом и последним коммитом, между двумя коммитами или ветками. Это незаменимый инструмент для просмотра изменений перед их добавлением (git add) или коммитом (git commit).
Примеры:

# Показать изменения в рабочем каталоге, которые еще НЕ добавлены в индекс (unstaged changes)
git diff

# Показать изменения, которые добавлены в индекс, но еще НЕ закоммичены (staged changes)
git diff --staged
# или
git diff --cached

# Показать разницу между двумя коммитами
git diff  

# Показать разницу между двумя ветками
git diff main develop

Используйте git diff перед git add . или git commit -a, чтобы точно понимать, какие изменения вы собираетесь зафиксировать. Это помогает избежать случайного коммита отладочного кода или нежелательных изменений. Также git diff часто используется при код-ревью для просмотра конкретных изменений между ветками.

git stash

Временно сохраняет ваши незакоммиченные изменения (как из рабочего каталога, так и из индекса), чтобы вы могли переключиться на другую ветку или выполнить другую операцию, не теряя свою текущую работу. Это как положить свою работу на полку, чтобы потом вернуться к ней. После того как вы закончили с другими делами, вы можете вернуть сохраненные изменения обратно.
Примеры:

# Сохранить текущие незакоммиченные изменения в 'stash'
git stash save "Работа над интерфейсом пользователя" # Необязательное сообщение

# Показать список сохраненных состояний ('stashes')
git stash list

# Применить последние сохраненные изменения и удалить их из списка stash
git stash pop

# Применить последние сохраненные изменения, но оставить их в списке stash
git stash apply

# Удалить последнее сохраненное состояние из списка
git stash drop

git stash — это спасение, когда вам срочно нужно переключиться на другую задачу (например, исправить баг в продакшене), но ваша текущая работа еще не готова к коммиту. Только не забывайте про сохраненные изменения в stash, со временем там может накопиться много всего, и будет сложно вспомнить, что к чему относится.

git reset

Команда с несколькими режимами, используемая в основном для отмены изменений. Она может перемещать указатель HEAD (и текущей ветки) на другой коммит, а также опционально изменять индекс (staging area) и рабочий каталог. Это мощная, но потенциально опасная команда, особенно в режиме --hard.
Примеры:

# Отменить 'git add' для файла (убрать из индекса, но оставить изменения в рабочем каталоге)
git reset HEAD имя_файла
# или более современный вариант: git restore --staged имя_файла

# Откатить последний коммит, но оставить изменения в рабочем каталоге и индексе (--soft)
git reset --soft HEAD~1

# Откатить последний коммит, оставить изменения в рабочем каталоге, но убрать из индекса (--mixed - это режим по умолчанию)
git reset HEAD~1

# Откатить последний коммит И УДАЛИТЬ все связанные с ним изменения из рабочего каталога и индекса (--hard - ОПАСНО!)
git reset --hard HEAD~1

Используйте git reset с осторожностью, особенно --hard, так как он безвозвратно удаляет незакоммиченные изменения. git reset также используется для отмены коммитов, которые еще не были отправлены на удаленный сервер. Если коммит уже опубликован (git push), для его отмены лучше использовать git revert, чтобы не переписывать общую историю.

Что дальше?

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

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

Задача: форкнуть репозиторий в 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.

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

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

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

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

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

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

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

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

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

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

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

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

Появится окно 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. Она покажет текущее состояние в вашей ветке, а именно список с названиями изменённых файлов, если они есть, и укажет на те, которые ожидают записи и сохранения (обычно они выделены красным цветом).

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

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.

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

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

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

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

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

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

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

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

Когда мы клонируем себе репозиторий с 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 ¯\_(ツ)_/¯