git clone: как клонировать репозиторий с GitHub и не только

Команда git clone создаёт полную локальную копию удалённого репозитория: файлы, всю историю коммитов, ветки и теги. Это стандартный способ начать работу с проектом, который уже лежит на GitHub, GitLab или корпоративном сервере. В отличие от скачивания ZIP-архива, клон — полноценный репозиторий, в котором можно коммитить и отправлять изменения обратно.

Базовое использование git clone

Скопируйте адрес репозитория (на GitHub — зелёная кнопка «Code») и выполните:

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

Cloning into 'project'...
remote: Enumerating objects: 1532, done.
remote: Counting objects: 100% (1532/1532), done.
remote: Compressing objects: 100% (812/812), done.
Receiving objects: 100% (1532/1532), 2.41 MiB | 6.10 MiB/s, done.
Resolving deltas: 100% (701/701), done.

Git создаст папку project в текущей директории (имя берётся из адреса без .git). Дальше переходите в неё:

cd project
git status

Что делает git clone под капотом

Клонирование — это не просто загрузка файлов. Понимание этих шагов объясняет, почему после клона всё «просто работает» и откуда берутся ветки с префиксом origin/. По шагам команда:

1. создаёт папку и выполняет в ней аналог git init;
2. добавляет remote с именем origin, указывающий на исходный адрес;
3. скачивает все объекты и ссылки — эквивалент git fetch;
4. создаёт удалённые ветки origin/main, origin/develop и так далее;
5. создаёт локальную ветку по умолчанию (обычно main), связывает её с origin/main и разворачивает файлы.

Поэтому после клона не нужно вручную настраивать git remote — git push и git pull сразу работают.

git remote -v
origin  https://github.com/username/project.git (fetch)
origin  https://github.com/username/project.git (push)

Клонирование по HTTPS и по SSH

Для чтения чужих открытых проектов достаточно HTTPS. Для своих репозиториев, куда вы регулярно пушите, удобнее SSH:

git clone git@github.com:username/project.git

Если уже склонировали по HTTPS и хотите перейти на SSH, перекачивать не нужно:

git remote set-url origin git@github.com:username/project.git

Как клонировать в определённую папку

Второй аргумент — имя или путь целевой директории:

# В папку с другим именем
git clone https://github.com/username/project.git my-copy

# В текущую папку (она должна быть пустой)
git clone https://github.com/username/project.git .

Если целевая папка существует и не пуста, Git откажется: fatal: destination path 'project' already exists and is not an empty directory.

Как клонировать конкретную ветку

По умолчанию после клона вы стоите на ветке по умолчанию удалённого репозитория. Чтобы сразу оказаться на другой, используйте -b (--branch):

git clone -b develop https://github.com/username/project.git

Обратите внимание: при этом скачиваются все ветки, вы просто окажетесь на develop. Если нужна только одна ветка без остальных, добавьте --single-branch:

git clone -b develop --single-branch https://github.com/username/project.git

Флаг -b принимает и имя тега — тогда вы получите состояние проекта на момент релиза (в режиме detached HEAD):

git clone -b v2.1.0 --depth 1 https://github.com/username/project.git

Где остальные ветки после клона

Новички удивляются: git branch показывает только main. Остальные ветки скачаны как удалённые, увидеть их можно так:

git branch -a

* main
  remotes/origin/HEAD -> origin/main
  remotes/origin/develop
  remotes/origin/feature/login

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

git switch develop

Неглубокий клон: --depth для больших репозиториев

У старых проектов история может весить гигабайты. Если вам нужен только текущий код — например, в CI или чтобы просто собрать проект, — скачайте последние коммиты:

git clone --depth 1 https://github.com/username/big-project.git

Флаг --depth подразумевает --single-branch, поэтому придут только ветка по умолчанию и один коммит. Если позже понадобится полная история, её можно докачать:

git fetch --unshallow

Можно указать и другую глубину, например --depth 50, или ограничить историю датой через --shallow-since=2025-01-01. Для активной разработки неглубокий клон неудобен: git log, git blame и поиск по истории будут неполными.

Частичный клон: --filter

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

git clone --filter=blob:none https://github.com/username/monorepo.git

Так вы сохраняете полную историю для log и переключения веток, но экономите трафик и место. Требует поддержки со стороны сервера; GitHub и GitLab её поддерживают.

Зеркальный клон и перенос репозитория

Обычный клон забирает ветки как удалённые и не копирует служебные ссылки сервера. Для переноса проекта на другой хостинг или создания резервной копии «один в один» используют --mirror:

git clone --mirror https://github.com/username/project.git
cd project.git
git push --mirror git@gitlab.com:username/project.git

Зеркало — это bare-репозиторий без рабочих файлов, в котором все ветки и теги хранятся как локальные. Команда git push --mirror отправит их на новый сервер целиком, и история перенесётся без потерь. Учтите, что задачи, pull request и настройки хостинга так не переносятся — это уже данные сервиса, а не Git.

Похожий флаг --bare тоже создаёт репозиторий без рабочей директории, но копирует только ветки и теги. Он подходит, чтобы развернуть центральный репозиторий на своём сервере из существующего проекта.

Клонирование с подмодулями

Если проект использует git submodules, по умолчанию их папки окажутся пустыми. Чтобы скачать всё сразу:

git clone --recurse-submodules https://github.com/username/project.git

Если уже склонировали без флага — догрузите подмодули:

git submodule update --init --recursive

git clone, fork и скачивание ZIP

Fork и clone не конкурируют: при работе с open source сначала делают fork на сайте, затем клонируют уже свой fork и добавляют оригинал вторым remote:

git clone git@github.com:me/project.git
cd project
git remote add upstream https://github.com/author/project.git
git fetch upstream

Частые ошибки git clone

«Repository not found»

Опечатка в адресе или репозиторий приватный, а у вас нет доступа. GitHub для приватных репозиториев намеренно отвечает «not found», а не «доступ запрещён». Проверьте адрес и то, что вы авторизованы под нужным аккаунтом.

«Permission denied (publickey)»

Клон по SSH, но ключ не настроен. Проверьте ssh -T git@github.com, добавьте публичный ключ в настройки аккаунта или временно склонируйте по HTTPS.

«Authentication failed» по HTTPS

Вы ввели пароль от аккаунта. GitHub давно требует Personal Access Token вместо пароля для операций Git по HTTPS. Если Git запомнил неверные данные — удалите их в менеджере учётных данных системы.

Обрыв на большом репозитории

Ошибки вида early EOF или RPC failed часто связаны с нестабильной сетью и размером. Помогает неглубокий клон --depth 1 с последующим git fetch --unshallow или клон по SSH.

Проблемы с переводами строк на Windows

После клона все файлы «изменены» — так проявляется конвертация CRLF/LF. Настройте git config --global core.autocrlf true на Windows (или input на Linux и macOS) и лучше задайте правила в .gitattributes проекта.

Что делать сразу после клонирования

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

1. Прочитайте README и CONTRIBUTING. Там обычно описано, как установить зависимости, запустить тесты и как в проекте принято называть ветки.
2. Проверьте ветку и состояние. git status и git log --oneline -5 покажут, где вы и какие последние изменения.
3. Создайте свою ветку. Не работайте прямо в main: git switch -c feature/my-task.
4. Проверьте автора коммитов. Если на компьютере несколько аккаунтов (личный и рабочий), задайте e-mail для конкретного репозитория без --global: git config user.email "you@company.com".
5. Установите зависимости. Папки вроде node_modules или venv в репозиторий не кладут, их создают локально: npm install, pip install -r requirements.txt и так далее.

Как поддерживать клон в актуальном состоянии

Клонирование выполняется один раз. Дальше новые коммиты коллег подтягиваются из того же origin:

# Посмотреть, что появилось на сервере, ничего не меняя
git fetch
git log --oneline main..origin/main

# Влить изменения в текущую ветку
git pull

Привычка сначала делать git fetch и смотреть, что пришло, спасает от неожиданных конфликтов. Повторно клонировать проект «чтобы обновить» не нужно — так теряются локальные ветки и незакоммиченная работа.

Шпаргалка по git clone

Итог

git clone скачивает репозиторий целиком и сразу настраивает связь с сервером через origin, поэтому после него можно коммитить, пушить и пуллить без дополнительной настройки. Для своих проектов используйте SSH, для больших — --depth или --filter, для нужной ветки — -b. Работа с удалёнными репозиториями, push, pull и fetch разобраны на практике в курсе по Git.