git-clone

Название

git-clone — клонирование репозитория в новый каталог

Краткое описание

git clone [--template=<template-directory>]
          [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
          [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
          [--dissociate] [--separate-git-dir <git-dir>]
          [--depth <depth>] [--[no-]single-branch] [--[no-]tags]
          [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
          [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow]
          [--filter=<filter-spec> [--also-filter-submodules]] [--] <repository>
          [<directory>]

Описание

Клонирует репозиторий в только что созданный каталог, создаёт ветки отслеживания удалённых веток для каждой ветки клонированного репозитория (их можно просмотреть с помощью git branch --remotes) и создаёт и переключается на начальную ветку, ответвлённую от текущей активной ветки клонированного репозитория.

После клонирования обычная команда git fetch без аргументов обновит все ветки отслеживания удалённых веток, а команда git pull без аргументов дополнительно объединит удалённую ветку master с текущей веткой master, если она существует (это неверно, если указан параметр --single-branch; см. ниже).

Эта конфигурация по умолчанию создаётся путём добавления ссылок на вершины веток удалённого репозитория в refs/remotes/origin и инициализации переменных конфигурации remote.origin.url и remote.origin.fetch.

Параметры

-l

--local

Если репозиторий, из которого выполняется клонирование, находится на локальном компьютере, этот флаг обходит обычный транспортный механизм «с поддержкой Git» и клонирует репозиторий, копируя HEAD и всё содержимое каталогов objects и refs. Файлы в каталоге .git/objects/ по возможности связываются жёсткими ссылками для экономии места.

Если репозиторий указан как локальный путь (например, /path/to/repo), этот режим используется по умолчанию, а --local фактически ничего не делает. Если репозиторий указан как URL, этот флаг игнорируется (локальные оптимизации не используются). Указание --no-local переопределит поведение по умолчанию, когда задан /path/to/repo, и вместо этого будет использоваться обычный транспорт Git.

Если $GIT_DIR/objects репозитория содержит символические ссылки или сам является символической ссылкой, клонирование завершится ошибкой. Это мера безопасности, предотвращающая непреднамеренное копирование файлов при разыменовании символических ссылок.

Из соображений безопасности этот параметр не работает с репозиториями, принадлежащими другим пользователям; для успешного клонирования необходимо указать --no-local.

ПРИМЕЧАНИЕ: эта операция может конфликтовать с одновременным изменением исходного репозитория, так же как выполнение cp -r <src> <dst> во время изменения <src>.

--no-hardlinks

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

-s

--shared

Если клонируемый репозиторий находится на локальном компьютере, вместо жёстких ссылок автоматически настроить .git/objects/info/alternates для совместного использования объектов с исходным репозиторием. В созданном репозитории изначально не будет собственных объектов.

Примечание

эта операция потенциально опасна; не используйте её, если не понимаете, что она делает. Если вы клонируете репозиторий с этим параметром, а затем удалите ветки (или воспользуетесь любой другой командой Git, делающей существующий коммит недоступным по ссылке) в исходном репозитории, некоторые объекты могут стать недоступными по ссылке (или осиротевшими). Эти объекты могут быть удалены обычными операциями Git (например, git commit), которые автоматически вызывают git maintenance run --auto. (См. git-maintenance[1].) Если эти объекты будут удалены, несмотря на то что на них ссылается клонированный репозиторий, этот репозиторий станет повреждённым.

Обратите внимание: запуск git repack без параметра --local в репозитории, клонированном с помощью --shared, скопирует объекты из исходного репозитория в пакет клонированного репозитория, устранив экономию дискового пространства, обеспечиваемую clone --shared. Однако безопасно запускать git gc, которая по умолчанию использует параметр --local.

Чтобы разорвать зависимость репозитория, клонированного с помощью --shared, от исходного репозитория, достаточно выполнить git repack -a, чтобы скопировать все объекты из исходного репозитория в пакет клонированного репозитория.

--reference=<repository>

--reference-if-able=<repository>

Если эталонный <repository> находится на локальном компьютере, автоматически настроить .git/objects/info/alternates для получения объектов из эталонного <repository>. Использование уже существующего репозитория в качестве альтернативного позволит скопировать меньше объектов из клонируемого репозитория, сократив затраты на сеть и локальное хранилище. При использовании --reference-if-able отсутствующий каталог пропускается с предупреждением, а не приводит к прерыванию клонирования.

Примечание

см. ПРИМЕЧАНИЕ к параметру --shared, а также описание параметра --dissociate.

--dissociate

Заимствовать объекты из эталонных репозиториев, указанных с помощью параметров --reference, только для сокращения сетевой передачи, а после завершения клонирования прекратить заимствование, создав необходимые локальные копии заимствованных объектов. Этот параметр также можно использовать при локальном клонировании репозитория, который уже заимствует объекты из другого репозитория: новый репозиторий будет заимствовать объекты из того же репозитория, а этот параметр позволит прекратить заимствование.

-q

--quiet

Работать в тихом режиме. Сведения о ходе выполнения не выводятся в стандартный поток ошибок.

-v

--verbose

Работать в подробном режиме. Не влияет на вывод сведений о ходе выполнения в стандартный поток ошибок.

--progress

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

--server-option=<option>

Передать указанную строку серверу при обмене данными с использованием протокола версии 2. Указанная строка не должна содержать символ NUL или LF. Обработка сервером параметров сервера, в том числе неизвестных, зависит от конкретного сервера. Если указано несколько параметров --server-option=<option>, все они передаются другой стороне в том порядке, в котором перечислены в командной строке. Если в командной строке не указан ни один параметр --server-option=<option>, вместо них используются значения переменной конфигурации remote.<name>.serverOption.

-n

--no-checkout

Не выполнять checkout HEAD после завершения клонирования.

--no-reject-shallow

--reject-shallow

Завершиться с ошибкой, если исходный репозиторий является неглубоким. Значение по умолчанию можно задать с помощью переменной конфигурации clone.rejectShallow.

--bare

Создать bare репозиторий Git. То есть вместо создания <directory> и размещения административных файлов в <directory>/.git сделать сам <directory> $GIT_DIR. Очевидно, это подразумевает --no-checkout, поскольку рабочее дерево некуда извлечь. Кроме того, заголовки веток на удалённом репозитории копируются непосредственно в соответствующие заголовки локальных веток, без сопоставления с refs/remotes/origin/. При использовании этого параметра не создаются ни ветки отслеживания удалённых репозиториев, ни связанные с ними переменные конфигурации.

--sparse

Использовать разреженную выгрузку: изначально будут присутствовать только файлы из корневого каталога. Команду git-sparse-checkout[1] можно использовать, чтобы при необходимости расширить рабочий каталог.

--filter=<filter-spec>

Использовать функцию частичного клонирования и запросить у сервера отправку подмножества достижимых объектов в соответствии с заданным фильтром объектов. При использовании --filter переданное значение <filter-spec> используется в качестве фильтра частичного клонирования.

При использовании --filter=auto спецификация фильтра определяется автоматически с помощью протокола promisor-remote (см. gitprotocol-v2[5]) путём объединения спецификаций фильтров, объявленных сервером для принимаемых клиентом promisor-remote (см. параметр конфигурации promisor.acceptFromServer в git-config[1]). Это позволяет серверу предложить оптимальный фильтр для доступных promisor-remote.

Как и другие спецификации фильтров, значение "auto" сохраняется в конфигурации. Благодаря этому последующие операции fetch будут и дальше адаптироваться к текущим рекомендациям сервера.

Сведения обо всех остальных доступных спецификациях фильтров см. в описании параметра --filter=<filter-spec> в git-rev-list[1].

Например, --filter=blob:none отфильтрует все blob-объекты (содержимое файлов), пока они не понадобятся Git. Кроме того, --filter=blob:limit=<size> отфильтрует все blob-объекты размером не менее <size>.

--also-filter-submodules

Также применить фильтр частичного клонирования ко всем подмодулям репозитория. Требуются параметры --filter и --recurse-submodules. Этот параметр можно включить по умолчанию, задав параметр конфигурации clone.filterSubmodules.

--mirror

Настроить зеркало исходного репозитория. Это подразумевает --bare. В отличие от --bare, --mirror сопоставляет не только локальные ветки исходного репозитория с локальными ветками целевого, но и все ссылки (включая ветки отслеживания удалённых репозиториев, заметки и т. д.), а также настраивает refspec таким образом, чтобы все эти ссылки перезаписывались командой git remote update в целевом репозитории.

-o<name>

--origin=<name>

Вместо имени удалённого репозитория origin, используемого для отслеживания вышестоящего репозитория, использовать <name>. Переопределяет значение clone.defaultRemoteName из конфигурации.

-b<name>

--branch=<name>

Указывает для только что созданного HEAD ветку <name> вместо ветки, на которую указывает HEAD клонируемого репозитория. В репозитории без рабочего дерева будет извлечена именно эта ветка. --branch также может принимать теги и отсоединяет HEAD на этом коммите в результирующем репозитории.

--revision=<rev>

Создать новый репозиторий и получить историю, ведущую к указанной ревизии <rev> (и ничего больше), не создавая ветку отслеживания удалённого репозитория и локальную ветку, и отсоединить HEAD на <rev>. Аргументом может быть имя ссылки (например, refs/heads/main или refs/tags/v1.0), которая разрешается в коммит, или шестнадцатеричное имя объекта. Эта опция несовместима с --branch и --mirror.

-u<upload-pack>

--upload-pack=<upload-pack>

Указать нестандартный путь к команде, запускаемой на другой стороне при доступе по ssh к клонируемому репозиторию.

--template=<template-directory>

Указать каталог, из которого будут использоваться шаблоны (см. раздел «КАТАЛОГ ШАБЛОНОВ» в git-init[1]).

-c<key>=<value>

--config=<key>=<value>

Задать переменную конфигурации в только что созданном репозитории; она вступит в силу сразу после инициализации репозитория, но до получения удалённой истории и извлечения каких-либо файлов. Значение <key> имеет тот же формат, что и ожидаемый командой git-config[1] (например, core.eol=true). Если для одного ключа указано несколько значений, каждое из них будет записано в файл конфигурации. Это позволяет, например, безопасно добавлять дополнительные refspecs для получения данных с удалённого репозитория origin.

Из-за ограничений текущей реализации некоторые переменные конфигурации вступают в силу только после первоначального получения данных и извлечения файлов. Известно, что не вступают в силу следующие переменные конфигурации: remote.<name>.mirror и remote.<name>.tagOpt. Вместо них используйте соответствующие опции --mirror и --no-tags.

--depth=<depth>

Создать shallow клон с историей, ограниченной указанным количеством коммитов. Подразумевает --single-branch, если не указана --no-single-branch, чтобы получить историю вблизи вершин всех веток. Чтобы клонировать подмодули с неглубокой историей, также передайте --shallow-submodules.

--shallow-since=<date>

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

--shallow-exclude=<ref>

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

--single-branch

--no-single-branch

Клонировать только историю, ведущую к вершине одной ветки, указанной опцией --branch или той, на которую указывает HEAD основной ветки удалённого репозитория. Последующие операции получения данных в результирующий репозиторий будут обновлять только ветку отслеживания удалённого репозитория для ветки, использованной при первоначальном клонировании. Если HEAD в удалённом репозитории не указывал на какую-либо ветку при создании клона с помощью --single-branch, ветка отслеживания удалённого репозитория не создаётся.

--tags

--no-tags

Управляет клонированием тегов. Если указана --no-tags, действие этой опции сохраняется в конфигурации remote.<remote>.tagOpt=--no-tags. Это гарантирует, что последующие команды git pull и git fetch не будут получать никакие теги. Явное получение тегов по-прежнему будет работать (см. git-fetch[1]).

По умолчанию теги клонируются, поэтому указание --tags обычно ничего не меняет, если только оно не отменяет ранее указанную --no-tags.

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

--recurse-submodules[=<pathspec>]

После создания клона инициализировать и клонировать подмодули в соответствии с указанным <pathspec>. Если =<pathspec> не указан, инициализируются и клонируются все подмодули. Этот параметр можно указать несколько раз для pathspec, состоящих из нескольких записей. В результате для клона будет задано значение submodule.active, соответствующее указанному pathspec, или "." (то есть все подмодули), если pathspec не указан.

Подмодули инициализируются и клонируются с настройками по умолчанию. Это эквивалентно запуску git submodule update --init --recursive <pathspec> сразу после завершения клонирования. Этот параметр игнорируется, если клонированный репозиторий не содержит рабочее дерево/рабочую копию (то есть если указан любой из параметров --no-checkout/-n, --bare или --mirror)

--shallow-submodules

--no-shallow-submodules

Все клонируемые подмодули будут поверхностными, с глубиной 1.

--remote-submodules

--no-remote-submodules

Для обновления каждого клонированного подмодуля будет использоваться состояние его отслеживаемой удалённой ветки, а не записанный SHA-1 суперпроекта. Эквивалентно передаче параметра --remote команде git submodule update.

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

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

--ref-format=<ref-format>

Указать формат хранения ссылок для репозитория. Допустимые значения:

files: для отдельных файлов с packed-refs. Используется по умолчанию.
reftable: для формата reftable.

-j<n>

--jobs=<n>

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

<repository>

Исходный <repository> (возможно, удалённый), из которого выполняется клонирование. Дополнительные сведения об указании репозиториев см. в разделе URL Git ниже.

<directory>

Имя нового каталога, в который выполняется клонирование. Если <directory> явно не указан, используется «человекочитаемая» часть исходного репозитория (repo для /path/to/repo.git и foo для host.xz:foo/.git). Клонирование в существующий каталог разрешено, только если он пуст.

--bundle-uri=<uri>

Перед получением данных с удалённого репозитория получить bundle по указанному <uri> и распаковать его данные в локальный репозиторий. Ссылки из bundle будут сохранены в скрытом пространстве имён refs/bundle/*. Этот параметр несовместим с --depth, --shallow-since и --shallow-exclude.

URL Git

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

Git поддерживает протоколы ssh, git, http и https (кроме того, для получения данных можно использовать ftp и ftps, но это неэффективно и считается устаревшим; не используйте их).

Встроенный транспорт (то есть URL git://) не выполняет аутентификацию, поэтому его следует с осторожностью использовать в незащищённых сетях.

Для них можно использовать следующие синтаксические формы:

ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>
git://<host>[:<port>]/<path-to-git-repo>
http[s]://<host>[:<port>]/<path-to-git-repo>
ftp[s]://<host>[:<port>]/<path-to-git-repo>

Для протокола ssh также можно использовать альтернативный синтаксис, похожий на scp:

[<user>@]<host>:/<path-to-git-repo>

Этот синтаксис распознаётся, только если перед первым двоеточием нет косых черт. Это позволяет отличить локальный путь, содержащий двоеточие. Например, локальный путь foo:bar можно указать как абсолютный путь или как ./foo:bar, чтобы его не приняли за URL ssh.

Протоколы ssh и git также поддерживают подстановку ~<username>:

ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>
git://<host>[:<port>]/~<user>/<path-to-git-repo>
[<user>@]<host>:~<user>/<path-to-git-repo>

Для локальных репозиториев, которые также поддерживаются Git напрямую, можно использовать следующие синтаксические формы:

/path/to/repo.git/
file:///path/to/repo.git/

Эти две формы в основном эквивалентны, за исключением того, что первая подразумевает параметр --local.

git clone, git fetch и git pull, но не git push, также принимают подходящий файл bundle. См. git-bundle[1].

Если Git не знает, как обрабатывать определённый транспортный протокол, он пытается использовать удалённый вспомогательный скрипт remote-<transport>, если такой существует. Чтобы явно указать удалённый вспомогательный скрипт, можно использовать следующий синтаксис:

<transport>::<address>

где <address> может быть путём, сервером и путём или произвольной строкой, похожей на URL и распознаваемой конкретным вызываемым удалённым вспомогательным скриптом. Подробнее см. gitremote-helpers[7].

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

        [url "<actual-url-base>"]
                insteadOf = <other-url-base>

Например, с такой конфигурацией:

        [url "git://git.host.xz/"]
                insteadOf = host.xz:/path/to/
                insteadOf = work:

URL, например "work:repo.git" или "host.xz:/path/to/repo.git", во всех контекстах, где требуется URL, будет преобразован в "git://git.host.xz/repo.git".

Чтобы преобразовывать URL только для отправки изменений, можно создать раздел конфигурации следующего вида:

        [url "<actual-url-base>"]
                pushInsteadOf = <other-url-base>

Например, с такой конфигурацией:

        [url "ssh://example.org/"]
                pushInsteadOf = git://example.org/

URL "git://example.org/path/to/repo.git" при отправке изменений будет преобразован в "ssh://example.org/path/to/repo.git", но для получения изменений по-прежнему будет использоваться исходный URL.

Примеры

Клонировать из upstream:

$ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux
$ cd my-linux
$ make

Создать локальный клон с заимствованием объектов из текущего каталога, не извлекая файлы рабочей копии:
```
$ git clone -l -s -n . ../copy
$ cd ../copy
$ git show-branch
```
Клонировать из upstream с заимствованием объектов из существующего локального каталога:
```
$ git clone --reference /git/linux.git \
        git://git.kernel.org/pub/scm/.../linux.git \
        my-linux
$ cd my-linux
```
Создать bare-репозиторий для публикации изменений:
```
$ git clone --bare -l /home/proj/.git /pub/scm/proj.git
```
Клонировать локальный репозиторий другого пользователя:
```
$ git clone --no-local /home/otheruser/proj.git /pub/scm/proj.git
```

Конфигурация

Всё, что находится ниже этой строки в данном разделе, выборочно включено из документации git-config[1]. Содержимое совпадает с тем, что приведено там:

init.templateDir: Указывает каталог, из которого будут копироваться шаблоны. (См. раздел «КАТАЛОГ ШАБЛОНОВ» в git-init[1].)
init.defaultBranch: Позволяет переопределить имя ветки по умолчанию, например при инициализации нового репозитория.
init.defaultObjectFormat: Позволяет переопределить формат объектов по умолчанию для новых репозиториев. См. --object-format= в git-init[1]. Параметр командной строки и переменная окружения GIT_DEFAULT_HASH имеют приоритет над этой настройкой.
init.defaultRefFormat: Позволяет переопределить формат хранения ссылок по умолчанию для новых репозиториев. См. --ref-format= в git-init[1]. Параметр командной строки и переменная окружения GIT_DEFAULT_REF_FORMAT имеют приоритет над этой настройкой.
init.defaultSubmodulePathConfig: Логическое значение, указывающее, должны ли команды git init и git clone автоматически устанавливать extensions.submodulePathConfig в значение true. Это позволяет всем новым репозиториям автоматически использовать расширение пути подмодуля. Если значение не задано, по умолчанию используется false.
clone.defaultRemoteName: Имя удалённого репозитория, создаваемого при клонировании репозитория. По умолчанию — origin. Его можно переопределить, передав параметр командной строки --origin.
clone.rejectShallow: Отклонять клонирование репозитория, если он является поверхностным; это поведение можно переопределить, передав параметр --reject-shallow в командной строке.
clone.filterSubmodules: Если задан фильтр частичного клонирования (см. --filter в git-rev-list[1]) и используется --recurse-submodules, применить фильтр также к подмодулям.

© 2005–2026 Linus Torvalds and others
Licensed under the GNU General Public License version 2.
https://git-scm.com/docs/git-clone