Русский ▾ Topics ▾ Latest version ▾ git-clone last updated in 2.54.0

НАЗВАНИЕ

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

ОБЗОР

git clone' [--template=<каталог-шаблонов>]
	  [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
	  [-o <имя>] [-b <имя>] [-u <upload-pack>] [--reference <репозиторий>]
	  [--dissociate] [--separate-git-dir <каталог-git>]
	  [--depth <глубина>] [--[no-]single-branch] [--[no-]tags]
	  [--recurse-submodules[=<спецификатор-пути>]] [--[no-]shallow-submodules]
	  [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow]
	  [--filter=<спецификатор-фильтра> [--also-filter-submodules]] [--] <репозиторий>
	  [<каталог>]

ОПИСАНИЕ

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

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

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

ПАРАМЕТРЫ

-l
--local

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

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

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

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

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

--no-hardlinks

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

-s
--shared

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

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

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

Если вы хотите избавиться от зависимостей репозитория, клонированного с --shared, от его исходного репозитория, вы можете просто запустить git repack -a, который скопирует все объекты из исходного репозитория в pack-файлы клонированного.

--reference=<репозиторий>
--reference-if-able=<репозиторий>

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

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

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

-q
--quiet

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

-v
--verbose

Включение подробного режима. Не влияет на вывод информацию о ходе выполнения в стандартный поток ошибок.

--progress

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

--server-option=<параметры>

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

-n
--no-checkout

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

--no-reject-shallow
--reject-shallow

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

--bare

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

--sparse

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

--filter=<спецификатор-фильтра>

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

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

Как и в случае с другими спецификациями фильтров, значение «auto» сохраняется в конфигурации. Это гарантирует, что будущие операции получения (fetch) будут продолжать адаптироваться к текущей рекомендации сервера.

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

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

--also-filter-submodules

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

--mirror

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

-o<имя>
--origin=<имя>

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

-b<имя>
--branch=<имя>

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

--revision=<редакция>

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

-u<пакет-отправки>
--upload-pack=<пакет-отправки>

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

--template=<каталог-шаблонов>

Задаёт каталог с шаблонами. (См. раздел «КАТАЛОГ ШАБЛОНОВ» в git-init[1])

-c<ключ>=<значение>
--config=<ключ>=<значение>

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

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

--depth=<глубина>

Создаёт «частичный» (shallow) клон с историей, усечённой до указанного количество коммитов. Ясли явно не передано --no-single-branch (что приведёт к загрузке последней истории всех ветвей), то данный параметр подразумевает --single-branch. Если вы хотите, чтобы подмодули тоже клонировались частично, то передайте также --shallow-submodules.

--shallow-since=<дата>

Создать частичный клон с историей начиная с указанной <даты>.

--shallow-exclude=<ссылка>

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

--single-branch
--no-single-branch

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

--tags
--no-tags

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

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

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

--recurse-submodules[=<спецификатор-пути>]

После того, как клон будет создан, инициализировать и клонировать его подмодули, соответствующие указанному <спецификатору-пути>. Если =<спецификатор-пути> не задан, то инициализируются и клонируются все подмодули. Этот параметр может быть указан несколько раз, чтобы задать спецификатор, состоящий из нескольких записей. В полученном клоне устанавливается переменная конфигурации 'submodule.active`, в качестве значения которой используется итоговый спецификатор пути или ".", если ни один не задан, что означает «все подмодули».

При инициализации и клонировании подмодулей используются их параметры по умолчанию. Данный параметр эквивалентен запуску git submodule update --init --recursive <спецификатор-пути> сразу после завершения клонирования. Если у клонированного репозитория нет рабочей копии или если переключение на текущую ветку после извлечения отключено (т.е. если задан один из параметров: --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>

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

--ref-format=<формат-ссылок>

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

files

для непакованных файлов с packed-refs. Это значение по умолчанию.

reftable

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

-j<n>
--jobs=<n>

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

<репозиторий>

(Возможно удалённый) <репозиторий>, который должен быть склонирован. См. подробности о том как задавать адрес репозитория в разделе URL-АДРЕСА GIT ниже.

<каталог>

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

--bundle-uri=<uri>

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

URL-АДРЕСА GIT

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

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

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

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

  • ssh://[<пользователь>@]<хост>[:<порт>]/<путь-к-репозиторию-git>

  • git://<хост>[:<порт>]/<путь-к-репозиторию-git>

  • http[s]://<хост>[:<порт>]/<путь-к-репозиторию-git>

  • ftp[s]://<хост>[:<порт>]/<путь-к-репозиторию-git>

В качестве альтернативы для протокола ssh можно также использовать scp-подобный синтаксис:

  • [<пользователь>@]<хост>:/<путь-к-репозиторию-git>

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

Кроме того протоколы ssh и git поддерживают расширение ~<имени-пользователя>:

  • ssh://[<пользователь>@]<хост>[:<порт>]/~<имя-пользователя>/<путь-к-репозиторию-git>

  • git://<хост>[:<порт>]/~<имя-пользователя>/<путь-к-репозиторию-git>

  • [<пользователь>@]<хост>:/~<имя-пользователя>/<путь-к-репозиторию-git>

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

  • /путь/к/репозиторию.git/

  • file:///путь/к/репозиторию.git/

Эти два синтаксиса по большей части эквивалентны, кроме того что первый подразумевает параметр --local.

git clone, git fetch и git pull, но не git push, также примут сформированный соответствующим образом pack-файл. См. git-bundle[1].

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

  • <транспорт>::<адрес>

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

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

	[url "<настоящая-база-url>"]
		insteadOf = <другая-база-url>

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

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

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

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

	[url "<настоящая-база-url>"]
		pushInsteadOf = <другая-база-url>

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

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

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

ПРИМЕРЫ

  • Клонирование из вышестоящего репозитория:

    $ 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

  • Клонировать из вышестоящего репозитория, «заимствуя» объекты для совместного использования из существующего локального каталога:

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

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

    $ 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

Задаёт каталог, из которого будут копироваться шаблоны. (See the "TEMPLATE DIRECTORY" section of 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

Отказаться от клонирования репозитория, если он является частичным (shallow); это поведение можно переопределить, передав параметр командной строки --reject-shallow.

clone.filterSubmodules

Если задан фильтр частичного клонирования (см. --filter в git-rev-list[1]) и используется --recurse-submodules, то применять фильтр также и к подмодулям.

GIT

Является частью пакета git[1]